Compiling BRP for AARCH64-Linux

N30dG
N30dG
Joined: 29 Feb 16
Posts: 89
Credit: 4,805,610
RAC: 0
Topic 198552

I'm trying to (cross)compile the BRP-App for AARCH64.

I simply modifyed the LINUX-ARMv7NEON-XCOMP-Part (too lazy to implement a extra funtion for AARCH64 ;) ) in Build.sh.

Replacing (set_arm_xcomp() Line 316-318):

export CC=arm-unknown-linux-gnueabi-gcc
export CXX=arm-unknown-linux-gnueabi-g++
export LD=arm-unknown-linux-gnueabi-ld


with:

export CC=aarch64-linux-gnu-gcc
export CXX=aarch64-linux-gnu-g++
export LD=aarch64-linux-gnu-ld

modifyed the CXX- and C-FLAGS (under $TARGET_LINUX_ARMV7 Line 1693-1694) from:

export CXXFLAGS="-march=armv7-a -mfpu=neon -mfloat-abi=hard $CXXFLAGS"
export CFLAGS="-march=armv7-a -mfpu=neon -mfloat-abi=hard $CFLAGS"


to

export CXXFLAGS="-march=armv8-a -mcpu=cortex-a53+simd $CXXFLAGS"
export CFLAGS="-march=armv8-a -mcpu=cortex-a53+simd $CFLAGS"

and finally removed the --enable-neon from Functions build_fftw() on Line 764 and build_fftw_ndk()on Line 803.
Because the AARCh64-gcc doesn't know this Option. Neon should be enabled by default.

After modifying that, the build can be almost done, except the last Step:Building Binary Radio Pulsar Search [Application]...
this gives me an Error:

/home/osboxes/BRP64/src/erp_boinc_wrapper.cpp:180: undefined reference to `backtrace_symbols_fd_plus'
collect2: error: ld returned 1 exit status
Makefile:73: recipe for target 'einsteinbinary_arm-unknown-linux-gnueabihf' failed
make: *** [einsteinbinary_arm-unknown-linux-gnueabihf] Error 1

The function backtrace_symbols_fd_plus is defined in erp_execinfo_plus.h & erp_execinfo_plus.cpp. So I think there is an Error in compiling these Files.

Are there any other Logfiles or something similar where I can see what causes these Error?

P.S. The rest of the Output in build.log are the same as the build.log when successful compiled for ARMv7.

N30dG
N30dG
Joined: 29 Feb 16
Posts: 89
Credit: 4,805,610
RAC: 0

Compiling BRP for AARCH64-Linux

Update:
The Problem is only this one function-call backtrace_symbols_fd_plus in erp_boinc_wrapper.cpp:180.
If I comment this line out, the compile is successfull.

Christian Beer
Christian Beer
Moderator
Joined: 9 Feb 05
Posts: 595
Credit: 100,068,514
RAC: 4,124

You can comment out all the

You can comment out all the erp_ files. they are not needed for the scientific part.

Bikeman (Heinz-Bernd Eggenstein)
Bikeman (Heinz-...
Moderator
Joined: 28 Aug 06
Posts: 3,516
Credit: 471,278,117
RAC: 54,182

Interesting

Interesting project.

Quote:

and finally removed the --enable-neon from Functions build_fftw() on Line 764 and build_fftw_ndk()on Line 803.
Because the AARCh64-gcc doesn't know this Option. Neon should be enabled by default.

I think you should keep the "--enable-neon": this is not an argument to gcc but to FFTW's configure script.

Some other things to consider:

The build script uses FFTW 3.3.2 . For the ARMv7 devices I've seen so far, this version gives the best performance. But for ARMv8, you might want to try FFTW 3.3.4, the latest version. Look for "3.3.2" in the build script and change accordingly.

Once you get this running, you can toy around with generating FFW wisdom for your specific host (see http://www.fftw.org/doc/Words-of-Wisdom_002dSaving-Plans.html ) to get better performance. The utility program that is used for this is generated alongside the BRP app in

install/bin/fftwf-wisdom

below the directory of the build script.

N30dG
N30dG
Joined: 29 Feb 16
Posts: 89
Credit: 4,805,610
RAC: 0

First Task's are running :)

First Task's are running :) :) :) Hopefully the results become valid.
Here is the Link to the Computer https://einsteinathome.org/host/12232054

Quote:
I think you should keep the "--enable-neon": this is not an argument to gcc but to FFTW's configure script.


No, im running into an Error keeping this argument. Because the configure-script only set's CFLAGS="-mfpu=neon". Maybe I have to modify the configure-script of FFTW. Or try a newer Version of the FFTW-lib at first.

Quote:
Once you get this running, you can toy around with generating FFW wisdom for your specific host (see http://www.fftw.org/doc/Words-of-Wisdom_002dSaving-Plans.html ) to get better performance. The utility program that is used for this is generated alongside the BRP app in


Thanks for suggestion. I will give it a try.

After the first result's are valid I try to optimize the App using your suggestions.

P.S. Only for my personal interest what does Wisdom to optimize the FFT?
Asking because I have build a 8-Band-Spectrum-Analyzer for Audio Purpose around 2 years ago. With logarithmical X-Axis & Y-Axis from 31,5Hz to 16Khz(8-Octaves).
Using only a 32Mhz 8bit CPU for calculating the FFT and reached an Updatespeed of >12Hz.
I think that is really fast(for that CPU) but more is better :P and maybe I can optimze it a little bit.

Bikeman (Heinz-Bernd Eggenstein)
Bikeman (Heinz-...
Moderator
Joined: 28 Aug 06
Posts: 3,516
Credit: 471,278,117
RAC: 54,182

RE: RE: I think you

Quote:

Quote:
I think you should keep the "--enable-neon": this is not an argument to gcc but to FFTW's configure script.

No, im running into an Error keeping this argument. Because the configure-script only set's CFLAGS="-mfpu=neon".

No, --enable-neon will also set the HAVE_NEON macro which does tons of things in FFTW compilation, so you are most likely now running a version that does not use the NEON vector FPU.

As far as I can see, the problem you ran into when compiling for AARCH64 was fixed only after the latest version of FFTW was released (3.3.4), but it is in the current development git, master branch, see https://github.com/FFTW/fftw3. Must be this change: https://github.com/FFTW/fftw3/commit/8aa91763af07767f3ebb71a9836a69e3b3385cab. It adds double precision FFT for AARCH64 (not needed for BRP) and also makes other adjustments for AARCH64 gcc .

Quote:

P.S. Only for my personal interest what does Wisdom to optimize the FFT?

Think of FFTW "wisdom" as recorded profiling results that will help FFTW to pick the best way to compute a given transfrom, selecting one of the many variants how to compute it.

Bikeman (Heinz-Bernd Eggenstein)
Bikeman (Heinz-...
Moderator
Joined: 28 Aug 06
Posts: 3,516
Credit: 471,278,117
RAC: 54,182

RE: First Task's are

Quote:
First Task's are running :) :) :) Hopefully the results become valid.
Here is the Link to the Computer https://einsteinathome.org/host/12232054

Congratulations, some results have validated and took between ca. 48k and 52k. That is OK but not great, a PI3 can do this in ca 38k sec, e.g. https://einsteinathome.org/host/12212487/tasks&offset=0&show_names=0&state=4&appid=, I guess with some modification to the FFTW build scripts as discussed above, you would be able to get better performance with NEON.

What kind of machine is this, anyway? An Odroid C2? I would not be surprised if a C2 could do BRP tasks in, say, 25k sec.

N30dG
N30dG
Joined: 29 Feb 16
Posts: 89
Credit: 4,805,610
RAC: 0

Thanks :), yes it's an

Thanks :), yes it's an ODROID-C2.

Unfortunately I can't get FFTW to work with the actual Master-Branch from GIT. With 3.3.4 it worked without any issues, but without NEON.

But the version from GIT gives me errors on ./configure

make[4]: Entering directory '/home/osboxes/BRP64/build/fftw/dft/scalar/codelets'
make[4]: *** No rule to make target 'n1_2.c', needed by 'all'.  Stop.
make[4]: Leaving directory '/home/osboxes/BRP64/build/fftw/dft/scalar/codelets'
Makefile:459: recipe for target 'all-recursive' failed
make[3]: *** [all-recursive] Error 1
make[3]: Leaving directory '/home/osboxes/BRP64/build/fftw/dft/scalar'
Makefile:494: recipe for target 'all-recursive' failed
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory '/home/osboxes/BRP64/build/fftw/dft'
Makefile:672: recipe for target 'all-recursive' failed
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory '/home/osboxes/BRP64/build/fftw'
Makefile:536: recipe for target 'all' failed
make: *** [all] Error 2

I really don't know why, have tried many different thinks, nothing worked. But for today it's enough for me. My Linux-Terminal has burned into my Eyes and I can see it if I close them ;P.

Bikeman (Heinz-Bernd Eggenstein)
Bikeman (Heinz-...
Moderator
Joined: 28 Aug 06
Posts: 3,516
Credit: 471,278,117
RAC: 54,182

I would try to go with 3.3.4

I would try to go with 3.3.4 and just apply the patch I mentioned above, or maybe even the part that deals with configure (basically delete the test that checks that gcc takes -mfpu=neon when --enable-neon is selected. Maybe that already helps.

N30dG
N30dG
Joined: 29 Feb 16
Posts: 89
Credit: 4,805,610
RAC: 0

RE: basically delete the

Quote:
basically delete the test that checks that gcc takes -mfpu=neon when --enable-neon is selected. Maybe that already helps.

Only trick the ./configure don't work, for doing this I don't have to manipulate it. Simple adding NEON_CFLAGS="-D__ARM_NEON__" to the end of the ./configure-call makes it.

But I'm running into many Error's. All from header-files that containing "neon" in her name. I try to switch the simd-neon.h to the changed one from git-repository. Maybe that helps.

N30dG
N30dG
Joined: 29 Feb 16
Posts: 89
Credit: 4,805,610
RAC: 0

Don't get it to work :(. Have

Don't get it to work :(. Have tried to apply the patch from GIT-hub manually, tried to manipulate the configure-script. Nothing worked.
And now I can't think any further myself. :(

Here's the make-log ([....]-reduced):

make[5]: Entering directory '/home/neo/BRP64/build/fftw/dft/simd/neon'
/bin/bash ../../../libtool  --tag=CC   --mode=compile aarch64-linux-gnu-gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I/home/neo/BRP64/3rdparty/fftw/dft/simd/neon -I../../..  -I/home/neo/BRP64/3rdparty/fftw/kernel -I/home/neo/BRP64/3rdparty/fftw/dft -I/home/neo/BRP64/3rdparty/fftw/dft/simd -I/home/neo/BRP64/3rdparty/fftw/simd-support  -D__ARM_NEON__ -O3 -fomit-frame-pointer  -fstrict-aliasing  -ffast-math  -I/home/neo/BRP64/install/include  -march=armv8-a -mcpu=cortex-a53+simd  -MT n1fv_2.lo -MD -MP -MF .deps/n1fv_2.Tpo -c -o n1fv_2.lo n1fv_2.c
libtool: compile:  aarch64-linux-gnu-gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I/home/neo/BRP64/3rdparty/fftw/dft/simd/neon -I../../.. -I/home/neo/BRP64/3rdparty/fftw/kernel -I/home/neo/BRP64/3rdparty/fftw/dft -I/home/neo/BRP64/3rdparty/fftw/dft/simd -I/home/neo/BRP64/3rdparty/fftw/simd-support -D__ARM_NEON__ -O3 -fomit-frame-pointer -fstrict-aliasing -ffast-math -I/home/neo/BRP64/install/include -march=armv8-a -mcpu=cortex-a53+simd -MT n1fv_2.lo -MD -MP -MF .deps/n1fv_2.Tpo -c n1fv_2.c -o n1fv_2.o
In file included from /home/neo/BRP64/3rdparty/fftw/simd-support/simd-neon.h:50:0,
                 from /home/neo/BRP64/3rdparty/fftw/dft/simd/n1f.h:21,
                 from /home/neo/BRP64/3rdparty/fftw/dft/simd/neon/../common/n1fv_2.c:71,
                 from n1fv_2.c:3:
/usr/lib/gcc/aarch64-linux-gnu/4.9/include/arm_neon.h: In function 'vqadd_u8':
/usr/lib/gcc/aarch64-linux-gnu/4.9/include/arm_neon.h:2116:3: error: incompatible types when returning type 'int' but 'uint8x8_t' was expected
   return __builtin_aarch64_uqaddv8qi_uuu (__a, __b);
   ^
/usr/lib/gcc/aarch64-linux-gnu/4.9/include/arm_neon.h: In function 'vqadd_u16':
/usr/lib/gcc/aarch64-linux-gnu/4.9/include/arm_neon.h:2122:3: error: incompatible types when returning type 'int' but 'uint16x4_t' was expected
   return __builtin_aarch64_uqaddv4hi_uuu (__a, __b);
   ^
/usr/lib/gcc/aarch64-linux-gnu/4.9/include/arm_neon.h: In function 'vqadd_u32':
/usr/lib/gcc/aarch64-linux-gnu/4.9/include/arm_neon.h:2128:3: error: incompatible types when returning type 'int' but 'uint32x2_t' was expected
   return __builtin_aarch64_uqaddv2si_uuu (__a, __b);
   ^
/usr/lib/gcc/aarch64-linux-gnu/4.9/include/arm_neon.h: In function 'vqaddq_u8':
/usr/lib/gcc/aarch64-linux-gnu/4.9/include/arm_neon.h:2165:3: error: incompatible types when returning type 'int' but 'uint8x16_t' was expected
   return __builtin_aarch64_uqaddv16qi_uuu (__a, __b);
   ^
/usr/lib/gcc/aarch64-linux-gnu/4.9/include/arm_neon.h: In function 'vqaddq_u16':
/usr/lib/gcc/aarch64-linux-gnu/4.9/include/arm_neon.h:2171:3: error: incompatible types when returning type 'int' but 'uint16x8_t' was expected
   return __builtin_aarch64_uqaddv8hi_uuu (__a, __b);
   ^
[....]
   ^
/usr/lib/gcc/aarch64-linux-gnu/4.9/include/arm_neon.h: In function 'vuqaddq_s32':
/usr/lib/gcc/aarch64-linux-gnu/4.9/include/arm_neon.h:24115:3: error: incompatible types when returning type 'int' but 'int32x4_t' was expected
   return __builtin_aarch64_suqaddv4si_ssu (__a,  __b);
   ^
/usr/lib/gcc/aarch64-linux-gnu/4.9/include/arm_neon.h: In function 'vuqaddq_s64':
/usr/lib/gcc/aarch64-linux-gnu/4.9/include/arm_neon.h:24121:3: error: incompatible types when returning type 'int' but 'int64x2_t' was expected
   return __builtin_aarch64_suqaddv2di_ssu (__a,  __b);
   ^
Makefile:739: recipe for target 'n1fv_2.lo' failed
make[5]: *** [n1fv_2.lo] Error 1
make[5]: Leaving directory '/home/neo/BRP64/build/fftw/dft/simd/neon'
Makefile:495: recipe for target 'all' failed
make[4]: *** [all] Error 2
make[4]: Leaving directory '/home/neo/BRP64/build/fftw/dft/simd/neon'
Makefile:376: recipe for target 'all-recursive' failed
make[3]: *** [all-recursive] Error 1
make[3]: Leaving directory '/home/neo/BRP64/build/fftw/dft/simd'
Makefile:488: recipe for target 'all-recursive' failed
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory '/home/neo/BRP64/build/fftw/dft'
Makefile:632: recipe for target 'all-recursive' failed
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory '/home/neo/BRP64/build/fftw'
Makefile:496: recipe for target 'all' failed
make: *** [all] Error 2

Any suggestions how to fix that?

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.