[U-Boot] Building qemu-x86_64_defconfig fails: u-boot-spl-nodtb.bin of 4, 293, 642, 704 bytes

[Heinrich Schuchardt]

On 09/11/2017 03:42 AM, Bin Meng wrote:
> Hi Heinrich,
> 
> On Sun, Sep 10, 2017 at 11:18 PM, Heinrich Schuchardt
> <xypron.glpk at 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 <schwab at 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
> 
Hello Bin,

using objcopy 2.25 does the same as 2.28:

objcopy -O binary -R .start16 -R .resetvec \
    u-boot-spl u-boot-spl-nodtb.bin

It creates the same 4G file when using the u-boot-spl file created on
Debian Stretch. But the u-boot-spl files are different on Debian Stretch
and Debian Jessie:

On Debian Stretch

objdump -h spl/u-boot-spl

  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
  5 .got.plt      0000000c  00120004  00120004  00001004  2**2
                  CONTENTS, ALLOC, LOAD, DATA
  6 .bss          00000900  00120020  00120020  00000000  2**5
                  ALLOC

.got            0x0000000000120000        0x4
 .got           0x0000000000120000        0x4 arch/x86/cpu/start.o

.got.plt        0x0000000000120004        0xc
 .got.plt       0x0000000000120004        0xc arch/x86/cpu/start.o
                0x0000000000120004        _GLOBAL_OFFSET_TABLE_

On Debian Jessie

objdump -h spl/u-boot-spl

  3 .data         00000268  fffdca80  fffdca80  0000da80  2**4
                  CONTENTS, ALLOC, LOAD, RELOC, DATA
  4 .bss          00000900  00120000  00120000  00000000  2**4
                  ALLOC

objcopy -O binary -R .start16 -R .resetvec \
	-R .got -R .got.plt  u-boot-spl u-boot-spl-nodtb.bin

creates a 51k file on both systems.

got refers to global offset table
plt refers to procedure linkage table

I have added patch
https://github.com/xypron2/u-boot/commit/5f1d9857a4bd7b629b58ac745001ceda04c85b8d
to
https://github.com/xypron2/u-boot/commits/spl-fix

I just want to wait for Travis CI to complete before sending it.

Best regards

Heinrich