Skip to content
This repository has been archived by the owner on Jul 16, 2021. It is now read-only.

setting target FPU #2

Closed
HerrMuellerluedenscheid opened this issue Mar 19, 2020 · 10 comments
Closed

setting target FPU #2

HerrMuellerluedenscheid opened this issue Mar 19, 2020 · 10 comments

Comments

@HerrMuellerluedenscheid
Copy link
Contributor

Hi,

This recipe compiles perfectly fine using qemu_x86-64 but unfortunately I'm stuck with the compilation for the target platform which is powered by an Allwinner H2 SoC. 'do_compile' fails with:

/home/marius/mender-orangepi-warrior/build/tmp/work/armv7vet2hf-neon-poky-linux-gnueabi/python3-scipy/1.3.3-r0/recipe-sysroot-native/usr/bin/arm-poky-linux-gnueabi/../../libexec/arm-poky-linux-gnueabi/gcc/arm-poky-linux-gnueabi/8.3.0/ld: error: build/lib.linux-x86_64-3.7/scipy/fftpack/_fftpack.cpython-37m-arm-linux-gnueabi.so uses VFP register arguments, build/temp.linux-x86_64-3.7/libfftpack.a(cffti1.o) does not
/home/marius/mender-orangepi-warrior/build/tmp/work/armv7vet2hf-neon-poky-linux-gnueabi/python3-scipy/1.3.3-r0/recipe-sysroot-native/usr/bin/arm-poky-linux-gnueabi/../../libexec/arm-poky-linux-gnueabi/gcc/arm-poky-linux-gnueabi/8.3.0/ld: failed to merge target specific data of file build/temp.linux-x86_64-3.7/libfftpack.a(cffti1.o)

[...]

| error: Command "/home/marius/mender-orangepi-warrior/build/tmp/work/armv7vet2hf-neon-poky-linux-gnueabi/python3-scipy/1.3.3-r0/recipe-sysroot-native/usr/bin/arm-poky-linux-gnueabi/arm-poky-linux-gnueabi-gcc -Wall -g -march=armv7ve -mthumb -mfpu=neon -mfloat-abi=hard -fstack-protector-strong -D_FORTIFY_SOURCE=2 -Wformat -Wformat-security -Werror=format-security --sysroot=/home/marius/mender-orangepi-warrior/build/tmp/work/armv7vet2hf-neon-poky-linux-gnueabi/python3-scipy/1.3.3-r0/recipe-sysroot -shared -Wl,-O1 -Wl,--hash-style=gnu -Wl,--as-needed -fstack-protector-strong -Wl,-z,relro,-z,now -L/home/marius/mender-orangepi-warrior/build/tmp/work/armv7vet2hf-neon-poky-linux-gnueabi/python3-scipy/1.3.3-r0/recipe-sysroot/usr/lib/python3.7/site-packages/numpy/core/lib build/temp.linux-x86_64-3.7/build/src.linux-x86_64-3.7/scipy/fftpack/_fftpackmodule.o build/temp.linux-x86_64-3.7/scipy/fftpack/src/zfft.o build/temp.linux-x86_64-3.7/scipy/fftpack/src/drfft.o build/temp.linux-x86_64-3.7/scipy/fftpack/src/zrfft.o build/temp.linux-x86_64-3.7/scipy/fftpack/src/zfftnd.o build/temp.linux-x86_64-3.7/build/src.linux-x86_64-3.7/scipy/fftpack/src/dct.o build/temp.linux-x86_64-3.7/build/src.linux-x86_64-3.7/scipy/fftpack/src/dst.o build/temp.linux-x86_64-3.7/build/src.linux-x86_64-3.7/build/src.linux-x86_64-3.7/scipy/fftpack/fortranobject.o -L/home/marius/mender-orangepi-warrior/build/tmp/work/armv7vet2hf-neon-poky-linux-gnueabi/python3-scipy/1.3.3-r0/recipe-sysroot/usr/lib -Lbuild/temp.linux-x86_64-3.7 -ldfftpack -lfftpack -lpython3.7m -lgfortran -o build/lib.linux-x86_64-3.7/scipy/fftpack/_fftpack.cpython-37m-arm-linux-gnueabi.so -Wl,--version-script=build/temp.linux-x86_64-3.7/link-version-scipy.fftpack._fftpack.map" failed with exit status 1
| ERROR: 'python3 setup.py build ' execution failed.

(Note the warning on the VFP register arguments)

I did some research and assume that it is linked to the floating point processing on the target device. I tried to enforce hard and soft FPU handling by setting target_FPU="soft" (or hard) in the machine configuration. In both cases compilation crashed at the same step.

Do you have an idea how to fix the compilation for this target machine?

@gpanders
Copy link
Owner

Unfortunately I won't be of much help to you here. You might want to try asking on the Yocto mailing list. Someone on there might have some experience compiling to your target.

@HerrMuellerluedenscheid
Copy link
Contributor Author

Ok. I'm in contact with the community throurgh their irc channel. I'll close the issue but will keep it updated as soon as a solution comes up.

@mcampbellizo
Copy link
Contributor

@HerrMuellerluedenscheid , we ran into a similar issue when compiling for the RPi 3. Our work around was to switch to soft float ABI and disable the VFP unit. This isn't a great solution as this has an impact on performance, but it goes us going. I'd be interested in hearing if you got any better solutions from talking to the larger community.

@HerrMuellerluedenscheid
Copy link
Contributor Author

@mcampbellizo Sure, I'm happy to keep you updated. For now, I would be super happy if the soft float ABI would work. Can you give me a hint on how you did that? So far I only found the TARGET_FPU switch which I set to soft but that did not do the trick, unfortunately. Given that we seem to have a pretty overpowered CPU for our task I most certainly can live with performance loss (for now).

@mcampbellizo
Copy link
Contributor

@HerrMuellerluedenscheid we had to change the DEFAULTTUNE variable in the machine conf file (in our case conf/machine/raspberrypi3.conf. The orignal value was

DEFAULTTUNE ?= "cortexa7thf-neon-vfpv4"

and we changed it to

DEFAULTTUNE ?= "cortexa7t-neon"

This changed from the hard float ABI To soft float ABI and disabled used of the vector floating point unit. The base cortexa7t might need to be different for your board if it's not an a7 core, but this should get you started. Let me know how this goes for you.

@HerrMuellerluedenscheid
Copy link
Contributor Author

HerrMuellerluedenscheid commented Mar 25, 2020

That works! I'll see how bad the performance loss is but for now this allows to compile this recipe on Allwinner H2 plus (branch: warrior)!

@mcampbellizo
Copy link
Contributor

That's awesome! We didn't get exact numbers but did note a measurable difference in at least Scipy performance. Depending on how bad it is for us we may investigate how to get this working with hard float and VFP enabled. Either way, do you think a note about needing to disable VFP and hard float with an example in the README.md seems like a good idea?

@gpanders
Copy link
Owner

I've just made the wiki for this repo publicly editable, so I think that would be a good place to add things like this. You can create a new page for your particular architecture/target with specific instructions. Let me know if you're not able to do so.

@yohboy
Copy link

yohboy commented Mar 28, 2020

Hi, I also ran into the same issue, changing the default tune worked (a9 core). I'm curious if someone finds a way to keep hard abi.

@erikboto
Copy link
Contributor

I'm also hitting this issue. Looking into a bit it seems like the issue is that the fortran compiler is not called with the -mfloat-abi -mfpu set as it should, so it generates soft-float binaries and then the linker complains when linking with the other objects file correctly compiled from C with correct float options.

I'll most likely be digging into this the next few days, and will provide updates here if I have any news.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants