[yocto] Problems building U-Boot for x86_64

Ferry Toth ftoth at telfort.nl
Fri Aug 25 15:30:42 PDT 2017


Op Fri, 25 Aug 2017 21:22:40 +0200, schreef Ferry Toth:

> Khem Raj wrote:
> 
> 
>> 
>> 
>> On 8/23/17 3:40 PM, Ferry Toth wrote:
>>> Op Wed, 23 Aug 2017 14:51:55 -0700, schreef Khem Raj:
>>> 
>>>> On 8/23/17 2:29 PM, Ferry Toth wrote:
>>>>> Ferry Toth wrote:
>>>>>
>>>>>> Khem Raj wrote:
>>>>>>
>>>>>>> On 8/22/17 11:41 PM, Ferry Toth wrote:
>>>>>>>> I am having trouble building a specific U-Boot version with
>>>>>>>> Yocto. Outside of Yocto on 64 bit Ubuntu 17.04 with multilib it
>>>>>>>> builds fine.
>>>>>>>>
>>>>>>>> I am extending meta-intel-edison to build a 64 bit Poke Morty,
>>>>>>>> with a vanilla 64-bit kernel (4.12). This is working quite well.
>>>>>>>>
>>>>>>>> My host is x86_64, the target is core2 with tune=core-64.
>>>>>>>>
>>>>>>>> Without 64bit tune I can build U-Boot fine. With 64bit it can not
>>>>>>>> link, appearently because it needs lbgcc.a
>>>>>>>
>>>>>>> what is exact error message ? is it while compiling host bits or
>>>>>>> target bits ?
>>>>>>
>>>>>> The failing line is:
>>>>>> x86_64-poky-linux-ld.bfd -Bsymbolic -Bsymbolic-functions -m
>>>>>> elf_i386 --emit- relocs --wrap=__divdi3 --wrap=__udivdi3
>>>>>> --wrap=__moddi3 --wrap=__umoddi3 -- gc-sections -pie -Bstatic
>>>>>> --no-dynamic-linker -Ttext 0x01101000 -o u-boot -T u-boot.lds
>>>>>> arch/x86/cpu/start.o --start-group arch/x86/cpu/built-in.o
>>>>>> arch/x86/lib/built-in.o board/intel/edison/built-in.o
>>>>>> cmd/built-in.o common/built-in.o disk/built-in.o drivers/built-in.o
>>>>>> drivers/dma/built-in.o drivers/gpio/built-in.o
>>>>>> drivers/i2c/built-in.o drivers/mmc/built-in.o
>>>>>> drivers/mtd/built-in.o drivers/mtd/onenand/built-in.o
>>>>>> drivers/mtd/spi/built- in.o drivers/net/built-in.o
>>>>>> drivers/net/phy/built-in.o drivers/pci/built- in.o
>>>>>> drivers/power/built-in.o drivers/power/battery/built-in.o
>>>>>> drivers/power/domain/built-in.o drivers/power/fuel_gauge/built-in.o
>>>>>> drivers/power/mfd/built-in.o drivers/power/pmic/built-in.o
>>>>>> drivers/power/regulator/built-in.o drivers/serial/built-in.o
>>>>>> drivers/spi/built-in.o drivers/usb/common/built-in.o
>>>>>> drivers/usb/dwc3/built- in.o drivers/usb/emul/built-in.o
>>>>>> drivers/usb/eth/built-in.o drivers/usb/gadget/built-in.o
>>>>>> drivers/usb/gadget/udc/built-in.o drivers/usb/host/built-in.o
>>>>>> drivers/usb/musb-new/built-in.o drivers/usb/musb/built-in.o
>>>>>> drivers/usb/phy/built-in.o drivers/usb/ulpi/built-in.o
>>>>>> dts/built-in.o fs/built-in.o lib/built-in.o net/built-in.o
>>>>>> test/built-in.o test/dm/built-in.o --end-group arch/x86/lib/lib.a
>>>>>> -Map u-boot.map ERROR: oe_runmake failed arch/x86/lib/built-in.o:
>>>>>> In function `__wrap___udivdi3':
>>>>>> /home/ferry/tmp/edison-intel/my/edison-
>>>>>> morty/out/linux64/build/tmp/work/edison-poky-linux/u-boot/edison-
>>> v2017.03-
>>>>>> r0/git/arch/x86/lib/gcc.c:25: undefined reference to
>>>>>> `__normal___udivdi3'
>>>>>
>>>>> I as believe the missing lib is libgcc.a I just my sysroot and found
>>>>> it here:
>>>>
>>>> the linker cmdline above does not link with libgcc and there might be
>>>> a good reason for that, many standalone applications dont link with
>>>> libgcc intentionally. You could look into the code and see if it can
>>>> be written differently such that gcc does not have to invoke a helper
>>>> function from gcc runtime. Another option is to link with libgcc
>>>> explicitly
>>> 
>>> If change my setup to build for a 32bit target, it build u-boot
>>> without error.
>> 
>> compiler may not be generating calls for the missing function.
>> 
>>> When I build the same git outside yocto on 64bit with multilib
>>> installed it also builds without error. In that case the make command
>>> would be: make -j8 edison_defconfig
>> 
>> same is possible. Can you do readelf -sW gcc.o and see if there is a
>> undefined reference to __normal___udivdi3
> 
>    20: 00000000    22 FUNC    GLOBAL HIDDEN     4 __wrap___divdi3 21:
>    00000000     0 NOTYPE  GLOBAL DEFAULT  UND __normal___divdi3 22:
>    00000000    22 FUNC    GLOBAL HIDDEN     6 __wrap___udivdi3 23:
>    00000000     0 NOTYPE  GLOBAL DEFAULT  UND __normal___udivdi3 24:
>    00000000    22 FUNC    GLOBAL HIDDEN     8 __wrap___moddi3 25:
>    00000000     0 NOTYPE  GLOBAL DEFAULT  UND __normal___moddi3 26:
>    00000000    22 FUNC    GLOBAL HIDDEN    10 __wrap___umoddi3 27:
>    00000000     0 NOTYPE  GLOBAL DEFAULT  UND __normal___umoddi3

AFAIKT when building for a 32-bit target is only that U-Boot makefile is 
called with CROSS_COMPILE=i686-poky-linux- CC=i686-poky-linux-gcc instead 
of CROSS_COMPILE=x86_64-poky-linux- CC=x86_64-poky-linux-gcc.

Result from readelf -sW gcc.o built wuth i686:

20: 00000000    27 FUNC    GLOBAL HIDDEN     4 __wrap___divdi3
21: 00000000     0 NOTYPE  GLOBAL DEFAULT  UND __normal___divdi3
22: 00000000    27 FUNC    GLOBAL HIDDEN     6 __wrap___udivdi3
23: 00000000     0 NOTYPE  GLOBAL DEFAULT  UND __normal___udivdi3
24: 00000000    27 FUNC    GLOBAL HIDDEN     8 __wrap___moddi3
25: 00000000     0 NOTYPE  GLOBAL DEFAULT  UND __normal___moddi3
26: 00000000    27 FUNC    GLOBAL HIDDEN    10 __wrap___umoddi3
27: 00000000     0 NOTYPE  GLOBAL DEFAULT  UND __normal___umoddi3

The path to libs and incs is the same (x86_64...) and I can't find any 
libgcc.a there. Still it links in this case.

Maybe in the 64-bit case I need to add i686-poky-linux-gcc to native and 
modify the recipe to use that?

>  
>>> My conclusion: I have some bb variable set to the wrong value or I
>>> need to get multilib installed into /..../sysroots/x86_64-linux/lib.
>>> 
>>> So how to do that?
>>> 
>>>>> sysroots/lib32-edison/usr/lib/i686-pokymllib32-linux/6.2.0/
>>>>> sysroots/lib32-edison-tcbootstrap/usr/lib/i686-pokymllib32-
linux/6.2.0/
>>>>> sysroots/edison/usr/lib64/x86_64-poky-linux/6.2.0/
>>>>> sysroots/edison-tcbootstrap/usr/lib64/x86_64-poky-linux/6.2.0/
>>>>>
>>>>> How compile log shows:
>>>>> NOTE: make -j8 CROSS_COMPILE=x86_64-poky-linux-
>>>>> CC=x86_64-poky-linux-gcc --sysroot=/..../sysroots/edison V=1
>>>>> HOSTCC=gcc -isystem/..../sysroots/x86_64-linux/usr/include -O2 -pipe
>>>>> -L/..../sysroots/x86_64-linux/usr/lib
>>>>> -L/..../sysroots/x86_64-linux/lib
>>>>> -Wl,-rpath-link,/..../sysroots/x86_64-linux/usr/lib
>>>>> -Wl,-rpath-link,/..../sysroots/x86_64-linux/lib
>>>>> -Wl,-rpath,/..../sysroots/x86_64-linux/usr/lib
>>>>> -Wl,-rpath,/..../sysroots/x86_64-linux/lib -Wl,-O1 -C
>>>>> /..../out/linux64/build/tmp/work/edison-poky-linux/u-boot/edison-
>>>>> v2017.03-r0/git
>>>>> O=/..../out/linux64/build/tmp/work/edison-poky-linux/u-
>>>>> boot/edison-v2017.03-r0/build edison_defconfig
>>>>>
>>>>> (.... my edits to shorten the uninteresting part of the path)
>>>>>
>>>>> I would think: --sysroot points to /edison dir which actually
>>>>> contains libgcc.a, but -i, _l and -W1 options point to host dirs
>>>>> that don't have the lib.
>>>>>
>>>>>
>>>>>>>> I attempted to add multilib, but although that immediately
>>>>>>>> exposed bugs in other recipes but actually adds libgcc.a, it does
>>>>>>>> that for the target sysroot only.
>>>>>>>>
>>>>>>>> And for some reason, U-Boot is built with the native gcc
>>>>>>>> (x86_64-linux),
>>>>>>>> and multilib does not add libgcc.a to that sysroot.
>>>>>>>>
>>>>>>>> So, how do I add multilib to -native sysroot, preferably only to
>>>>>>>> -native and not to the target, as the target has not further use
>>>>>>>> for it?
>>>>>>>>
>>>>>>>> Strangest thing is in u-boot.inc there is:
>>>>>>>> EXTRA_OEMAKE = 'CROSS_COMPILE=${TARGET_PREFIX}
>>>>>>>> CC="${TARGET_PREFIX}gcc ${TOOLCHAIN_OPTIONS}" V=1'
>>>>>>>> EXTRA_OEMAKE += 'HOSTCC="${BUILD_CC} ${BUILD_CFLAGS}
>>>>>>>> ${BUILD_LDFLAGS}"'
>>>>>>>>
>>>>>>>> But when I check my log file:
>>>>>>>> NOTE: make -j8 CROSS_COMPILE=x86_64-poky-linux-
>>>>>>>> CC=x86_64-poky-linux- gcc  ......
>>>>>>>>
>>>>>>>> So TARGET_PREFIX resolves to x86_64-poky-linux, but I think my
>>>>>>>> target is core2_64 (or something like that). Is that normal for
>>>>>>>> U-Boot?
>>>>>>>
>>>>>>> thats ok.
>>>>>>>
>>>>>>>
>>>>>>>> I am a little lost, so any help would be greatly appreciated!
>>>>>>>>
>>>>>>>> Ferry
>>>>>>>>
>>>>>>>>
>>>>>>> --
>>>>>>
>>>>>>
>>>>>> --
>>> 
>>> 
>> --





More information about the yocto mailing list