search

analogdevicesinc / buildroot

Buildroot is a simple, efficient and easy-to-use tool to generate embedded Linux systems through cross-compilation. Forked from https://git.busybox.net/buildroot/
Other
38 stars 59 forks source link

build problem with Vitis 2022.1 #69

Closed catkira closed 11 months ago

catkira commented 2 years ago

When I build buildroot, I get this error

Unable to detect the toolchain sysroot, Buildroot cannot use this toolchain.

I used these settings

export CROSS_COMPILE=arm-linux-gnueabihf-
export PATH=$PATH:/tools/Xilinx/Vitis/2022.1/gnu/aarch32/lin/gcc-arm-linux-gnueabi/bin

I checked where this error comes from. It is the file helpers.mk in the buildroot/toolchain folder.

libc_a_path=`$${__CROSS_CC} -print-file-name=libc.a` ; \
if test "$${libc_a_path}" = "libc.a" ; then \
   echo "Unable to detect the toolchain sysroot, Buildroot cannot use this toolchain." ; \
   exit 1 ; \
fi ;

I think the problem is that with the new Vitis libc.a is in a different folder, its in /tools/Xilinx/Vitis/2022.1/gnu/aarch32/lin/gcc-arm-none-eabi/aarch32-xilinx-eabi/usr/lib

but the gcc compiler is in /tools/Xilinx/Vitis/2022.1/gnu/aarch32/lin/gcc-arm-linux-gnueabi/bin

The Makefile just looks for where the compiler is and takes that as the toolchain path

#gives us path/bin/arm-linux-gnueabihf-gcc
TOOLCHAIN = $(shell which $(CROSS_COMPILE)gcc)
#gives us path/bin
TOOLCHAIN2 = $(shell dirname $(TOOLCHAIN))
#gives us path we need
TOOLCHAIN_PATH = $(shell dirname $(TOOLCHAIN2))

which results in /tools/Xilinx/Vitis/2022.1/gnu/aarch32/lin/gcc-arm-linux-gnueabi/ as toolchain path.

Does anybody have an idea how to fix this?

mhennerich commented 2 years ago

Hi,

I also came across this. Also no idea how to fix this. I continue to use an older Xilinx toolchain for buildroot.

export PATH=$PATH:/opt/Xilinx/SDK/2019.1/gnu/aarch32/lin/gcc-arm-linux-gnueabi/bin export CROSS_COMPILE=arm-linux-gnueabihf-

The other alternative is to use the buildroot toolchain option.

-Michael

catkira commented 2 years ago

How do You use the "buildroot toolchain option"?

mhennerich commented 2 years ago

That's what we did for microblaze https://github.com/analogdevicesinc/buildroot/commit/dd6dd8ec0cb302c7b446bbfba950bd6c088304c3

catkira commented 2 years ago

I think the problem is that the script in helpers.mk tries to find the path of libc.a by doing this

/tools/Xilinx/Vitis/2022.1/gnu/aarch32/lin/gcc-arm-linux-gnueabi/bin/arm-linux-gnueabihf-gcc -print-file-name=libc.a

but this retuns only "libc.a" without any path for Vitis 2022.1.

benja@DESKTOP:/tools/Xilinx/Vitis/2022.1/gnu/aarch32/lin/gcc-arm-linux-gnueabi$ /tools/Xilinx/Vitis/2022.1/gnu/aarch32/lin/gcc-arm-linux-gnueabi/bin/arm-linux-gnueabihf-gcc -print-file-name=libc.a
libc.a

When I do the same command with my system gcc (Ubuntu 20) I get this:

benja@DESKTOP:/tools/Xilinx/Vitis/2022.1/gnu/aarch32/lin/gcc-arm-linux-gnueabi$ gcc -print-file-name=libc.a
/usr/lib/gcc/x86_64-linux-gnu/9/../../../x86_64-linux-gnu/libc.a
catkira commented 2 years ago

@mhennerich I dont have vivado2019 installed. Can You check if the 2019 sdk returns the full path when doing

/opt/Xilinx/SDK/2019.1/gnu/aarch32/lin/gcc-arm-linux-gnueabi/bin/arm-linux-gnueabihf-gcc -print-file-name=libc.a

?

mhennerich commented 2 years ago

$ arm-linux-gnueabihf-gcc -print-file-name=libc.a /opt/Xilinx/SDK/2019.1/gnu/aarch32/lin/gcc-arm-linux-gnueabi/bin/../arm-linux-gnueabihf/libc/usr/lib/libc.a

catkira commented 2 years ago

ok, so thats probably the root cause of the problem.

catkira commented 2 years ago

The funny thing is, print-file-name does not give an error the file does not exist

benja@DESKTOP:/tools/Xilinx/Vitis/2022.1/gnu/aarch32/lin/gcc-arm-linux-gnueabi$ /tools/Xilinx/Vitis/2022.1/gnu/aarch32/lin/gcc-arm-linux-gnueabi/bin/arm-linux-gnueabihf-gcc -print-file-name=libcabcdefg.a
libcabcdefg.a

So I guess when there is an output name without path, it just means that the file is not found.

catkira commented 2 years ago

It finds the file (with path) when I specify the sysroot

benja@DESKTOP:/tools/Xilinx/Vitis/2022.1/gnu/aarch32/lin/gcc-arm-linux-gnueabi$ /tools/Xilinx/Vitis/2022.1/gnu/aarch32/lin/gcc-arm-linux-gnueabi/bin/arm-linux-gnueabihf-gcc -print-file-name=libc.a --sysroot=/tools/Xilinx/Vitis/2022.1/gnu/aarch32/lin/gcc-arm-none-eabi/aarch32-xilinx-eabi
/tools/Xilinx/Vitis/2022.1/gnu/aarch32/lin/gcc-arm-none-eabi/aarch32-xilinx-eabi/usr/lib/libc.a

So it should work, if we could tell buildroot to use this sysroot somehow. Do You know how to do that?

Edit: I added the --sysroot manually in helpers.mk to test it, but it did not work:

make[1]: Entering directory '/mnt/d/git/plutosdr-fw/buildroot'
>>> toolchain-external-custom  Configuring
cc1: fatal error: /mnt/d/git/plutosdr-fw/buildroot/libc.a/usr/include/linux/version.h: No such file or directory
compilation terminated.
make[1]: *** [package/pkg-generic.mk:240: /mnt/d/git/plutosdr-fw/buildroot/output/build/toolchain-external-custom/.stamp_configured] Error 1
make[1]: Leaving directory '/mnt/d/git/plutosdr-fw/buildroot'
make: *** [Makefile:123: buildroot/output/images/rootfs.cpio.gz] Error 2

But maybe this did not totally work, because --sysroot ... needs to be added everywhere. It would probably have to be added to __CROSS_CC

catkira commented 2 years ago 
benja@DESKTOP:/tools/Xilinx/Vitis/2022.1/gnu/aarch32/lin/gcc-arm-none-eabi/bin$ arm-none-eabi-gcc -print-file-na
me=libc.a
/usr/share/gcc-arm-none-eabi-10-2020-q4-major/bin/../lib/gcc/arm-none-eabi/10.2.1/../../../../arm-none-eabi/lib/libc.a

arm-none-eabi-gcc finds a libc.a, but I dont think thats the right one because its in /usr/share and from 2020.

mhennerich commented 2 years ago

I contacted someone at AMD/Xilinx to ask about this. But I got and out of office reply. For now I would use a different toolchain with buildroot.

catkira commented 2 years ago

but my laptop does not have endless storage :P

Edit:Ok, I installed the SDK, only 10 gig, I was afraid of another 100 gig...

catkira commented 2 years ago

with the 2019.1 sdk gcc-arm-linux-gnueabi and arm-none-eabi-gcc both give a valid path for libc.a

benja@DESKTOP:/tools/Xilinx/SDK/2019.1/gnu/aarch32/lin/gcc-arm-linux-gnueabi/bin$ ./arm-linux-gnueabihf-gcc -pri
nt-file-name=libc.a
/tools/Xilinx/SDK/2019.1/gnu/aarch32/lin/gcc-arm-linux-gnueabi/bin/../arm-linux-gnueabihf/libc/usr/lib/libc.a
benja@DESKTOP:/tools/Xilinx/SDK/2019.1/gnu/aarch32/lin/gcc-arm-none-eabi/bin$ ./arm-none-eabi-gcc -print-file-na
me=libc.a
/tools/Xilinx/SDK/2019.1/gnu/aarch32/lin/gcc-arm-none-eabi/bin/../arm-none-eabi/libc/usr/lib/libc.a

with Vitis 2022.1 it looks like this

benja@DESKTOP:/tools/Xilinx/Vitis/2022.1/gnu/aarch32/lin/gcc-arm-none-eabi/bin$ ./arm-none-eabi-gcc -print-file-
name=libc.a
./../aarch32-xilinx-eabi/usr/lib/libc.a
benja@DESKTOP:/tools/Xilinx/Vitis/2022.1/gnu/aarch32/lin/gcc-arm-linux-gnueabi/bin$ ./arm-linux-gnueabihf-gcc -p
rint-file-name=libc.a
libc.a

arm-linux-gnueabihf gives no path!

I guess it is supposed to find libc.a. at this path /tools/Xilinx/Vitis/2022.1/gnu/aarch32/lin/gcc-arm-linux-gnueabi/cortexa9t2hf-neon-xilinx-linux-gnueabi/lib

but there is also another one at this path /tools/Xilinx/Vitis/2022.1/gnu/aarch32/lin/gcc-arm-linux-gnueabi/x86_64-petalinux-linux/lib

maybe the user has to specify which one to use in Vitis? One could try to see what command line options for gcc is used when something is compiled with the vitis gui...

Edit: ah no, /tools/Xilinx/Vitis/2022.1/gnu/aarch32/lin/gcc-arm-linux-gnueabi/cortexa9t2hf-neon-xilinx-linux-gnueabi does not have libc.a, it only has libc.so.6

catkira commented 2 years ago

Ah I am getting a bit closer: I thought lin/gcc-arm-linux-gnueabi/cortexa9t2hf-neon-xilinx-linux-gnueabi must be the right sysroot dir to use. But in lin/gcc-arm-linux-gnueabi/cortexa9t2hf-neon-xilinx-linux-gnueabi/lib is no libc.a only a libc.so.6 . So I tried 

arm-linux-gnueabihf-gcc -print-file-name=libc.so.6

which gave 

/tools/Xilinx/Vitis/2022.1/gnu/aarch32/lin/gcc-arm-linux-gnueabi/bin/../cortexa9t2hf-neon-xilinx-linux-gnueabi/lib/libc.so.6

I think the problem is that Vitis 2022.1 does not use libc.a anymore, but libc.so.x. But buildroot tries to use libc.a . I dont know if its intended by Xilinx not to include the static libs.

It seems to be a known problem: https://support.xilinx.com/s/question/0D52E000079OJNCSA4/vitis-20221-is-missing-libca?language=en_US

But I think its also a bit lame that buildroot is hardcoded to libc.a, what if somebody only wants to use shared libs.

catkira commented 2 years ago

I made an ugly fix (the idea is that libc.a is only used by buildroot but not for actual compilations)

benja@DESKTOP:/tools/Xilinx/Vitis/2022.1/gnu/aarch32/lin/gcc-arm-linux-gnueabi/cortexa9t2hf-neon-xilinx-linux-gnueabi/lib$ sudo touch libc.a

But not there is another error

make -C buildroot TOOLCHAIN_EXTERNAL_INSTALL_DIR=/tools/Xilinx/Vitis/2022.1/gnu/aarch32/lin/gcc-arm-linux-gnueabi ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- BUSYBOX_CONFIG_FILE=/mnt/d/git/plutosdr-fw/buildroot/board/pluto/busybox-1.25.0.config all
make[1]: Entering directory '/mnt/d/git/plutosdr-fw/buildroot'
>>> toolchain-external-custom  Configuring
/tools/Xilinx/Vitis/2022.1/gnu/aarch32/lin/gcc-arm-linux-gnueabi/bin/arm-linux-gnueabihf-gcc
/tools/Xilinx/Vitis/2022.1/gnu/aarch32/lin/gcc-arm-linux-gnueabi/bin/../cortexa9t2hf-neon-xilinx-linux-gnueabi/lib/libc.a
/tools/Xilinx/Vitis/2022.1/gnu/aarch32/lin/gcc-arm-linux-gnueabi/cortexa9t2hf-neon-xilinx-linux-gnueabi/
Incorrect selection of kernel headers: expected 4.14.x, got 5.14.x

ok, I changed the kernel headers with menuconfig. Now another try...

GCC also needed to be changed from 8.x to 11.x

lol, there is a problem, in menuconfig 10.x is the highest. I guess buildroot needs to be updated. @mhennerich whats to best way to get upstream buildroot updates to this branch?

catkira commented 2 years ago

I can cherry pick the right commit from upstream and PR it into this repo

https://github.com/buildroot/buildroot/commit/cbaabbd42f9c632691ba78babb8f41084fa2e356 https://github.com/buildroot/buildroot/commit/2ab88dac293aed5adf2504e8b182f9d8a306b935 https://github.com/buildroot/buildroot/commit/b28e598cec6d2f51715505a7b88d9d6f39453371 https://github.com/buildroot/buildroot/commit/cc0630763d4e69abe2e8e950b21472f4bc6dc348

new kernel headers would also be nice https://github.com/buildroot/buildroot/commit/28983ccc0368006c8c749eb8a60bd4812be8461e https://github.com/buildroot/buildroot/commit/47523da623d81464fd48586ea265f5dc26a4d93f https://github.com/buildroot/buildroot/commit/73a55011419030bc1efedc8ef81e3f1a5ec33d3b https://github.com/buildroot/buildroot/commit/85459426d9f4f5909b359d9456f71bdeac3c46ff https://github.com/buildroot/buildroot/commit/2b134f9549dacd73621be11bb7894bacd3c7b0a1

but just merging upstream master into this branch is probably the easiest. Do You usually do merge or rebase?

catkira commented 2 years ago

@mhennerich I see You merged tag '2021.02.7' from upstream. Why did You chose such an old tag? It does not support the GCC used with Vitis 2022.1. Is it possible that You merge a newer tag?

nunojsa commented 2 years ago

Well, at the time it was the logical one to merge. Note we merged at November 16, 2021 which was 6 days after 2021.02.7 if I'm not mistaken.

Is it possible that You merge a newer tag?

Eventually that will surely happen (some 2022.02.x tag) but I cannot say when it will...

catkira commented 2 years ago

is it useful if I merge tag 2022.05 from upstream to master of adi buildroot and do a PR?

Or is there a specific reason You want to have 2022.02.x?

nunojsa commented 2 years ago

Or is there a specific reason You want to have 2022.02.x?

AFAIK, 2022.02 is the LTS release which means is the one we want to merge with. That said, we typically don't really need to backport any bugfix from buildroot but yeah, who knows :)...

is it useful if I merge tag 2022.05 from upstream to master of adi buildroot and do a PR?

Don't take me wrong but normally this kind of stuff is hard to review and normally we prefer to do it ourselves (so, if we screw things up, it's our mess :D).

catkira commented 2 years ago

ah ok. Can You antedate the merge of of tag 2022.2.x a bit? I think its the last missing piece to get buildroot running with Vitis 2022.1.

nunojsa commented 2 years ago

Well, I cannot really spend much time doing the merge atm but I will give it a try tomorrow. Luckily, it won't consume much time and I can get it done.

catkira commented 2 years ago

@nunojsa I tried to merge the 2022.02.3 tag just for fun to improve my git skills. When doing just

git merge 2022.02.3

I had do solve endless conflicts, that takes quite a while even when using kdiff3 and just doing ctrl+3, ctrl+q all the time. So instead I tried

git merge -s recursive -X theirs 2022.02.3

with that there were much less conflicts to manually solve (just deleted files on remote). I wonder is this the way how a Git pro would do it or does this might lose adi specific patches that we want to keep?

edit: seems like -s recursive -X theirs generates incorrect merge results

make -C buildroot legal-info
make[1]: Entering directory '/mnt/d/git/plutosdr-fw/buildroot'
package/alsa-lib/alsa-lib.mk:76: *** extraneous 'else'.  Stop.

edit2: I managed to merge it with -X theirs, after handfixing some things (for about 2-3 hours) target pluto compiles. But I dont feel super confident about it, I am not sure if I took the smartest approach. Happy to learn how to do it more efficient :)

nunojsa commented 2 years ago

git merge -s recursive -X theirs 2022.02.3

Well, I don't really know the details of the recursive strategy other than it can create less conflicts in some cases but I'm really not sure if it's the best one to use. Passing theirs might also not be the best option... However, in this case it's true that we mostly want whatever changes we have upstream. We need to be careful with libiio though.

That said, this was the step that helped me a lot last time:

https://github.com/analogdevicesinc/buildroot/commit/666c6bef261f47c08fd67967ab1fbfb17b74d305

The commit message should be enough to understand the idea. Sure, this does not look to great for git history but it helps a lot with the merge.

catkira commented 2 years ago

after copying libc.a from vitis 2022.1 windows installation to linux, I get this error

RPC support not available in C library, please disable BR2_TOOLCHAIN_EXTERNAL_INET_RPC
make: *** [package/pkg-generic.mk:283: /mnt/d/git/plutosdr-fw/buildroot/output/build/toolchain-external-custom/.stamp_configured] Error 1

I think its not because I copied libc.a from windows, it should be the same right?

nunojsa commented 2 years ago

I think its not because I copied libc.a from windows, it should be the same right?

Not sure but I would not assume that.

catkira commented 2 years ago

after disabling BR2_TOOLCHAIN_EXTERNAL_INET_RPC everything compiles.

I copied libc.a from D:\Xilinx\Vitis\2022.1\gnu\aarch32\nt\gcc-arm-linux-gnueabi\cortexa9t2hf-neon-xilinx-linux-gnueabi\usr\lib to the corresponding directory of my linux install.

@mhennerich You were already talking to somebody at Xilinx right? Can You tell them this finding? I wont file another bug report then.

catkira commented 2 years ago

git merge -s recursive -X theirs 2022.02.3

Well, I don't really know the details of the recursive strategy other than it can create less conflicts in some cases but I'm really not sure if it's the best one to use. Passing theirs might also not be the best option... However, in this case it's true that we mostly want whatever changes we have upstream. We need to be careful with libiio though.

That said, this was the step that helped me a lot last time:

666c6be

The commit message should be enough to understand the idea. Sure, this does not look to great for git history but it helps a lot with the merge.

I still dont fully understand the revert method. How do You make sure that there are no ADI commits in the range 2020.02..2020.02.8? You dont want to revert ADI commits, because they would be lost then right?

I was also afraid I might lose some adi stuff in ad936x or libiio, but I think the 'theirs' strategy will only come into effect, if there is a conflict. And when doing the normal merge, I did not see conflicts in the files modified by ADI. Thats why I chose to use 'theirs', but I agree its dangerous. I will do a diff of my merge against Yours once You are done. I am curious what the result will be.

nunojsa commented 2 years ago

@catkira,

I just created:

https://github.com/analogdevicesinc/buildroot/tree/master-next

If you want to give it a try... :+1:

catkira commented 2 years ago

should all the defconfigs for the ADI boards also be updated to newer kernel headers and GCCs? ATM the user has to modify the kernel headers and GCC version manually, if something newer than SDK 2019.1 is used. I also had to disable BR2_TOOLCHAIN_EXTERNAL_INET_RPC for Vitis 2022.1.

The problem is that even if the user changes the toolchain settings via 'make menuconfig', the new settings will be lost after every 'make', because the makefile will copy defconfig to .config and overwrite previous changes. Ideally the makefile will detect kernel header and gcc version of the installed vitis version, but I think for now its more practical to decide which vitis version should be supported by default - 2021.1 or 2022.1 ?

catkira commented 2 years ago

When compiling buildroot from the plutosdr-fw repo I get this error

/mnt/d/git/plutosdr-fw/buildroot/output/host/bin/arm-linux-gnueabihf-gcc-ar: line 3: /mnt/d/git/plutosdr-fw/buildroot/output/host/bin/../x86*/usr/bin/arm-xilinx-linux-gnueabi/arm-xilinx-linux-gnueabi-gcc-ar: No such file or directory
make[3]: *** [Makefile:396: libkernel.la] Error 127
make[3]: Leaving directory '/mnt/d/git/plutosdr-fw/buildroot/output/build/fftw-double-3.3.8/kernel'
make[2]: *** [Makefile:708: all-recursive] Error 1
make[2]: Leaving directory '/mnt/d/git/plutosdr-fw/buildroot/output/build/fftw-double-3.3.8'
make[1]: *** [Makefile:552: all] Error 2
make[1]: Leaving directory '/mnt/d/git/plutosdr-fw/buildroot/output/build/fftw-double-3.3.8'
make: *** [package/pkg-generic.mk:293: /mnt/d/git/plutosdr-fw/buildroot/output/build/fftw-double-3.3.8/.stamp_built] Error 2
make: Leaving directory '/mnt/d/git/plutosdr-fw/buildroot'
root@LAPTOP-Benjamin:/mnt/d/git/plutosdr-fw#

It happens during the last step when doing the build

 make -C buildroot TOOLCHAIN_EXTERNAL_INSTALL_DIR=/tools/Xilinx/Vitis/2022.1/gnu/aarch32/lin/gcc-arm-linux-gnueabi ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- BUSYBOX_CONFIG_FILE=/mnt/d/git/plutosdr-fw/buildroot/board/pluto/busybox-1.25.0.config all

I can reproduce the same error message when doing this:

root@LAPTOP-Benjamin:/mnt/d/git/plutosdr-fw/buildroot/output/host/bin# ./arm-linux-gnueabihf-ar
./arm-linux-gnueabihf-ar: line 3: ./../x86_64-petalinux-linux/usr/bin/arm-xilinx-linux-gnueabi/arm-xilinx-linux-gnueabi-ar: No such file or directory

arm-linux-gnueabihf-ar is a symlink to the vitis installation

lrwxrwxrwx 1 root root     91 Jul 19 21:45 arm-linux-gnueabihf-ar -> /tools/Xilinx/Vitis/2022.1/gnu/aarch32/lin/gcc-arm-linux-gnueabi/bin/arm-linux-gnueabihf-ar

The problem seems to be that somehow there is a relative path hardcoded into ar

 ./../x86_64-petalinux-linux/usr/bin/arm-xilinx-linux-gnueabi/arm-xilinx-linux-gnueabi-ar: No such file or directory

When I run arm-xilinx-linux-gnueabi-ar from inside the vitis installation dir the error does not pop up:

root@LAPTOP-Benjamin:/mnt/d/git/plutosdr-fw/buildroot/output/host/bin# /tools/Xilinx/Vitis/2022.1/gnu/aarch32/lin/gcc-arm-linux-gnueabi/bin/arm-linux-gnueabihf-ar
Usage: /tools/Xilinx/Vitis/2022.1/gnu/aarch32/lin/gcc-arm-linux-gnueabi/bin/../x86_64-petalinux-linux/usr/bin/arm-xilinx-linux-gnueabi/arm-xilinx-linux-gnueabi-ar.real [emulation options] [-]{dmpqrstx}[abcDfilMNoOPsSTuvV] [--plugin <name>] [member-name] [count] archive-file file...
       /tools/Xilinx/Vitis/2022.1/gnu/aarch32/lin/gcc-arm-linux-gnueabi/bin/../x86_64-petalinux-linux/usr/bin/arm-xilinx-linux-gnueabi/arm-xilinx-linux-gnueabi-ar.real -M [<mri-script]
 commands:
  d            - delete file(s) from the archive
  m[ab]        - move file(s) in the archive
  p            - print file(s) found in the archive
  q[f]         - quick append file(s) to the archive

The content of arm-linux-gnueabihf-ar looks like this and reveals the problem

#!/bin/bash
CC="`dirname $0`/../x86_64-petalinux-linux/usr/bin/arm-xilinx-linux-gnueabi/arm-xilinx-linux-gnueabi-ar"
$CC "$@"

In SDK 2019.1 arm-linux-gnueabihf-ar is a real binary and therefore this problem does not exist:

root@LAPTOP-Benjamin:/tools/Xilinx/SDK/2019.1/gnu/aarch32/lin/gcc-arm-linux-gnueabi/bin# ls -la arm-linux-gnueabihf-ar
-rwxr-xr-x 2 root root 1008728 May  8  2019 arm-linux-gnueabihf-ar

A simple fix would be to replace the relative path with an absolute path, but that would mean that every user has to patch his Vitis installation. But since 2022.1 seems to be broken anyway (with libc.a missing in the linux installation) a patch is needed anyway. @nunojsa @mhennerich ADI could provide the user a short guide how to patch Vitis 2022.1 so that it becomes ADI compatible. I think they are bugs by Xilinx and will probably get fixed in later releases. So far the following things have to be fixed:

  1. copy libc.a from Vitis 2022.1 windows installation to the Vitis 2022.1 linux installation
  2. change relative path in arm-linux-gnueabihf-ar and arm-linux-gnueabihf-gcc-ar and arm-linux-gnueabihf-gcc-ranlib to absolute path
#!/bin/bash
CC="/tools/Xilinx/Vitis/2022.1/gnu/aarch32/lin/gcc-arm-linux-gnueabi/x86_64-petalinux-linux/usr/bin/arm-xilinx-linux-gnueabi/arm-x>$CC "$@"
catkira commented 2 years ago

The fftw-double package still has a problem. fftw3.so is not generated. However when I run configure --enable-shared in output/build/fftw3 and then make it is generated. So I think --build-shared might have to be added to fftw3.mk

But it seems like --build-shared is already there:

./configure --target=arm-buildroot-linux-gnueabihf --host=arm-buildroot-linux-gnueabihf --build=x86_64-pc-linux-gnu --prefix=/usr --exec-prefix=/usr --sysconfdir=/etc --localstatedir=/var --program-prefix="" --disable-gtk-doc --disable-gtk-doc-html --disable-doc --disable-docs --disable-documentation --with-xmlto=no --with-fop=no --disable-dependency-tracking --enable-ipv6 --disable-nls --disable-static --enable-shared --disable-fortran --enable-threads --with-combined-threads --disable-openmp
catkira commented 2 years ago

I solved the fftw problem. The problem was that /tools/Xilinx/Vitis/2022.1/gnu/aarch32/lin/gcc-arm-linux-gnueabi/bin/arm-linux-gnueabihf-ld also had relative paths inside. I dont know why Xilinx does such stupid things, it means that these files can only run properly if working dir is same as the file location. I suggest that we write something about it in the README.md file, so that the users can patch their Vitis installation themselves.

This for example is nm, I did not patch it yet because it does not generate an error. 

#!/bin/bash
CC=`dirname $0`/../x86*/usr/bin/arm-xilinx-linux-gnueabi/arm-xilinx-linux-gnueabi-nm
$CC $@

But its probably wise to patch all files in /tools/Xilinx/Vitis/2022.1/gnu/aarch32/lin/gcc-arm-linux-gnueabi/bin. We can provide a sample linux command to the users in README.md that does this job.

catkira commented 2 years ago

now i get this error

CMake Error at iiod/CMakeLists.txt:39 (message):
  Unable to find libaio dependency.

  If you want to disable async.  I/O support, set WITH_AIO=OFF.
...
CMake Error: The following variables are used in this project, but they are set to NOTFOUND.
Please set them or make sure they are set and tested correctly in the CMake files:
LIBAIO_INCLUDE_DIR
   used as include directory in directory /mnt/d/git_fix/plutosdr-fw/buildroot/output/build/libiio-0.24/iiod
   used as include directory in directory /mnt/d/git_fix/plutosdr-fw/buildroot/output/build/libiio-0.24/iiod
   used as include directory in directory /mnt/d/git_fix/plutosdr-fw/buildroot/output/build/libiio-0.24/iiod
   used as include directory in directory /mnt/d/git_fix/plutosdr-fw/buildroot/output/build/libiio-0.24/iiod
   used as include directory in directory /mnt/d/git_fix/plutosdr-fw/buildroot/output/build/libiio-0.24/iiod
   used as include directory in directory /mnt/d/git_fix/plutosdr-fw/buildroot/output/build/libiio-0.24/iiod
   used as include directory in directory /mnt/d/git_fix/plutosdr-fw/buildroot/output/build/libiio-0.24/iiod
LIBAIO_LIBRARIES
    linked by target "iiod" in directory /mnt/d/git_fix/plutosdr-fw/buildroot/output/build/libiio-0.24/iiod

but libaio was installed

>>> libaio 0.3.112 Installing to target
PATH="/mnt/d/git_fix/plutosdr-fw/buildroot/output/host/bin:/mnt/d/git_fix/plutosdr-fw/buildroot/output/host/sbin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/usr/lib/wsl/lib:/snap/bin:/tools/Xilinx/Vitis/2022.1/gnu/aarch32/lin/gcc-arm-linux-gnueabi/bin" AR="/mnt/d/git_fix/plutosdr-fw/buildroot/output/host/bin/arm-linux-gnueabihf-gcc-ar" AS="/mnt/d/git_fix/plutosdr-fw/buildroot/output/host/bin/arm-linux-gnueabihf-as" LD="/mnt/d/git_fix/plutosdr-fw/buildroot/output/host/bin/arm-linux-gnueabihf-ld" NM="/mnt/d/git_fix/plutosdr-fw/buildroot/output/host/bin/arm-linux-gnueabihf-gcc-nm" CC="/mnt/d/git_fix/plutosdr-fw/buildroot/output/host/bin/arm-linux-gnueabihf-gcc" GCC="/mnt/d/git_fix/plutosdr-fw/buildroot/output/host/bin/arm-linux-gnueabihf-gcc" CPP="/mnt/d/git_fix/plutosdr-fw/buildroot/output/host/bin/arm-linux-gnueabihf-cpp" CXX="/mnt/d/git_fix/plutosdr-fw/buildroot/output/host/bin/arm-linux-gnueabihf-g++" FC="/mnt/d/git_fix/plutosdr-fw/buildroot/output/host/bin/arm-linux-gnueabihf-gfortran" F77="/mnt/d/git_fix/plutosdr-fw/buildroot/output/host/bin/arm-linux-gnueabihf-gfortran" RANLIB="/mnt/d/git_fix/plutosdr-fw/buildroot/output/host/bin/arm-linux-gnueabihf-gcc-ranlib" READELF="/mnt/d/git_fix/plutosdr-fw/buildroot/output/host/bin/arm-linux-gnueabihf-readelf" STRIP="/mnt/d/git_fix/plutosdr-fw/buildroot/output/host/bin/arm-linux-gnueabihf-strip" OBJCOPY="/mnt/d/git_fix/plutosdr-fw/buildroot/output/host/bin/arm-linux-gnueabihf-objcopy" OBJDUMP="/mnt/d/git_fix/plutosdr-fw/buildroot/output/host/bin/arm-linux-gnueabihf-objdump" AR_FOR_BUILD="/usr/bin/ar" AS_FOR_BUILD="/usr/bin/as" CC_FOR_BUILD="/usr/bin/gcc" GCC_FOR_BUILD="/usr/bin/gcc" CXX_FOR_BUILD="/usr/bin/g++" LD_FOR_BUILD="/usr/bin/ld" CPPFLAGS_FOR_BUILD="-I/mnt/d/git_fix/plutosdr-fw/buildroot/output/host/include" CFLAGS_FOR_BUILD="-O2 -I/mnt/d/git_fix/plutosdr-fw/buildroot/output/host/include" CXXFLAGS_FOR_BUILD="-O2 -I/mnt/d/git_fix/plutosdr-fw/buildroot/output/host/include" LDFLAGS_FOR_BUILD="-L/mnt/d/git_fix/plutosdr-fw/buildroot/output/host/lib -Wl,-rpath,/mnt/d/git_fix/plutosdr-fw/buildroot/output/host/lib" FCFLAGS_FOR_BUILD="" DEFAULT_ASSEMBLER="/mnt/d/git_fix/plutosdr-fw/buildroot/output/host/bin/arm-linux-gnueabihf-as" DEFAULT_LINKER="/mnt/d/git_fix/plutosdr-fw/buildroot/output/host/bin/arm-linux-gnueabihf-ld" CPPFLAGS="-D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64" CFLAGS="-D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64  -Os -g0 -D_FORTIFY_SOURCE=1" CXXFLAGS="-D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64  -Os -g0 -D_FORTIFY_SOURCE=1" LDFLAGS="" FCFLAGS=" -Os -g0" FFLAGS=" -Os -g0" PKG_CONFIG="/mnt/d/git_fix/plutosdr-fw/buildroot/output/host/bin/pkg-config" STAGING_DIR="/mnt/d/git_fix/plutosdr-fw/buildroot/output/host/arm-buildroot-linux-gnueabihf/sysroot" INTLTOOL_PERL=/usr/bin/perl PATH="/mnt/d/git_fix/plutosdr-fw/buildroot/output/host/bin:/mnt/d/git_fix/plutosdr-fw/buildroot/output/host/sbin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/usr/lib/wsl/lib:/snap/bin:/tools/Xilinx/Vitis/2022.1/gnu/aarch32/lin/gcc-arm-linux-gnueabi/bin" /usr/bin/make -j9 -C /mnt/d/git_fix/plutosdr-fw/buildroot/output/build/libaio-0.3.112 DESTDIR=/mnt/d/git_fix/plutosdr-fw/buildroot/output/target install
make[2]: Entering directory '/mnt/d/git_fix/plutosdr-fw/buildroot/output/build/libaio-0.3.112'
make[2]: 'install' is up to date.
make[2]: Leaving directory '/mnt/d/git_fix/plutosdr-fw/buildroot/output/build/libaio-0.3.112'

libaio is created here buildroot/build/libaio-0.3.112/src/libaio.so.1.0.1 but not getting installed...

@nunojsa I think this also happens with SDK 2019.1. Can You check if its related to the upstream merge?

something here is not working

 /usr/bin/make -j9 -C /mnt/d/git_fix/plutosdr-fw/buildroot/output/build/libaio-0.3.112 DESTDIR=/mnt/d/git_fix/plutosdr-fw/buildroot/output/target install
make[2]: Entering directory '/mnt/d/git_fix/plutosdr-fw/buildroot/output/build/libaio-0.3.112'
make[2]: 'install' is up to date.

the lib is getting installed when I do

/mnt/d/git_fix/plutosdr-fw/buildroot/output/build/libaio-0.3.112/src$ make DESTDIR=/mnt/d/git_fix/plutosdr-fw/buildroot/output/target install

but not when I execute the same command in /mnt/d/git_fix/plutosdr-fw/buildroot/output/build/libaio-0.3.112/

catkira commented 2 years ago

I it works when I add all as dependency to the install target in the Makefile of libai

--- Makefile.orig       2022-07-22 16:18:03.697464100 +0200
+++ Makefile    2022-07-22 16:15:54.786296000 +0200
@@ -13,7 +13,7 @@
 all:
        @$(MAKE) -C src

-install:
+install: all
        @$(MAKE) -C src install prefix=$(DESTDIR)$(prefix) includedir=$(DESTDIR)$(includedir) libdir=$(DESTDIR)$(libdir)
         $(info $(MAKE) -C src install prefix=$(DESTDIR)$(prefix) includedir=$(DESTDIR)$(includedir) libdir=$(DESTDIR)$(libdir))

can some Makefile expert explain why this is needed?

catkira commented 2 years ago

After everything has compiled successfully I get this error

>>>   Finalizing host directory
>>>   Finalizing target directory
mkdir -p /mnt/d/git/plutosdr-fw/buildroot/output/host/etc/meson
sed -e "s%@TARGET_CFLAGS@%'-D_LARGEFILE_SOURCE', '-D_LARGEFILE64_SOURCE', '-D_FILE_OFFSET_BITS=64', '-Os', '-g0', '-D_FORTIFY_SOURCE=1'@PKG_TARGET_CFLAGS@%g" -e "s%@TARGET_LDFLAGS@%@PKG_TARGET_LDFLAGS@%g" -e "s%@TARGET_CXXFLAGS@%'-D_LARGEFILE_SOURCE', '-D_LARGEFILE64_SOURCE', '-D_FILE_OFFSET_BITS=64', '-Os', '-g0', '-D_FORTIFY_SOURCE=1'@PKG_TARGET_CXXFLAGS@%g"         -e "s%@TARGET_CC@%/mnt/d/git/plutosdr-fw/buildroot/output/host/bin/arm-linux-gnueabihf-gcc%g" -e "s%@TARGET_CXX@%/mnt/d/git/plutosdr-fw/buildroot/output/host/bin/arm-linux-gnueabihf-g++%g" -e "s%@TARGET_AR@%/mnt/d/git/plutosdr-fw/buildroot/output/host/bin/arm-linux-gnueabihf-gcc-ar%g" -e "s%@TARGET_STRIP@%/mnt/d/git/plutosdr-fw/buildroot/output/host/bin/arm-linux-gnueabihf-strip%g" -e "s%@TARGET_ARCH@%arm%g" -e "s%@TARGET_CPU@%cortex-a9%g" -e "s%@TARGET_ENDIAN@%little%g" -e "s%@TARGET_CFLAGS@%%g" -e "s%@TARGET_LDFLAGS@%%g" -e "s%@TARGET_CXXFLAGS@%%g" -e "s%@BR2_CMAKE@%/usr/bin/cmake%g" -e "s%@PKGCONF_HOST_BINARY@%/mnt/d/git/plutosdr-fw/buildroot/output/host/bin/pkgconf%g" -e "s%@HOST_DIR@%/mnt/d/git/plutosdr-fw/buildroot/output/host%g" -e "s%@STAGING_DIR@%/mnt/d/git/plutosdr-fw/buildroot/output/host/arm-buildroot-linux-gnueabihf/sysroot%g" -e "s%@STATIC@%false%g" /mnt/d/git/plutosdr-fw/buildroot/support/misc/cross-compilation.conf.in > /mnt/d/git/plutosdr-fw/buildroot/output/host/etc/meson/cross-compilation.conf.in
sed         -e "s%@TARGET_CC@%/mnt/d/git/plutosdr-fw/buildroot/output/host/bin/arm-linux-gnueabihf-gcc%g" -e "s%@TARGET_CXX@%/mnt/d/git/plutosdr-fw/buildroot/output/host/bin/arm-linux-gnueabihf-g++%g" -e "s%@TARGET_AR@%/mnt/d/git/plutosdr-fw/buildroot/output/host/bin/arm-linux-gnueabihf-gcc-ar%g" -e "s%@TARGET_STRIP@%/mnt/d/git/plutosdr-fw/buildroot/output/host/bin/arm-linux-gnueabihf-strip%g" -e "s%@TARGET_ARCH@%arm%g" -e "s%@TARGET_CPU@%cortex-a9%g" -e "s%@TARGET_ENDIAN@%little%g" -e "s%@TARGET_CFLAGS@%'-D_LARGEFILE_SOURCE', '-D_LARGEFILE64_SOURCE', '-D_FILE_OFFSET_BITS=64', '-Os', '-g0', '-D_FORTIFY_SOURCE=1'%g" -e "s%@TARGET_LDFLAGS@%%g" -e "s%@TARGET_CXXFLAGS@%'-D_LARGEFILE_SOURCE', '-D_LARGEFILE64_SOURCE', '-D_FILE_OFFSET_BITS=64', '-Os', '-g0', '-D_FORTIFY_SOURCE=1'%g" -e "s%@BR2_CMAKE@%/usr/bin/cmake%g" -e "s%@PKGCONF_HOST_BINARY@%/mnt/d/git/plutosdr-fw/buildroot/output/host/bin/pkgconf%g" -e "s%@HOST_DIR@%/mnt/d/git/plutosdr-fw/buildroot/output/host%g" -e "s%@STAGING_DIR@%/mnt/d/git/plutosdr-fw/buildroot/output/host/arm-buildroot-linux-gnueabihf/sysroot%g" -e "s%@STATIC@%false%g" /mnt/d/git/plutosdr-fw/buildroot/support/misc/cross-compilation.conf.in > /mnt/d/git/plutosdr-fw/buildroot/output/host/etc/meson/cross-compilation.conf
/bin/sed -i -e '/# GENERIC_SERIAL$/s~^.*#~ttyPS0::respawn:/sbin/getty -L  ttyPS0 0 vt100 #~' /mnt/d/git/plutosdr-fw/buildroot/output/target/etc/inittab
/bin/sed -i -e '/^#.*-o remount,rw \/$/s~^#\+~~' /mnt/d/git/plutosdr-fw/buildroot/output/target/etc/inittab
if grep -q CONFIG_ASH=y /mnt/d/git/plutosdr-fw/buildroot/output/build/busybox-1.35.0/.config; then grep -qsE '^/bin/ash$' /mnt/d/git/plutosdr-fw/buildroot/output/target/etc/shells || echo "/bin/ash" >> /mnt/d/git/plutosdr-fw/buildroot/output/target/etc/shells; fi
if grep -q CONFIG_HUSH=y /mnt/d/git/plutosdr-fw/buildroot/output/build/busybox-1.35.0/.config; then grep -qsE '^/bin/hush$' /mnt/d/git/plutosdr-fw/buildroot/output/target/etc/shells || echo "/bin/hush" >> /mnt/d/git/plutosdr-fw/buildroot/output/target/etc/shells; fi
mkdir -p /mnt/d/git/plutosdr-fw/buildroot/output/target/etc
echo "pluto" > /mnt/d/git/plutosdr-fw/buildroot/output/target/etc/hostname
/bin/sed -i -e '$a \127.0.1.1\tpluto' -e '/^127.0.1.1/d' /mnt/d/git/plutosdr-fw/buildroot/output/target/etc/hosts
mkdir -p /mnt/d/git/plutosdr-fw/buildroot/output/target/etc
echo "Welcome to Pluto" > /mnt/d/git/plutosdr-fw/buildroot/output/target/etc/issue
/bin/sed -i -e s,^root:[^:]*:,root:"`/mnt/d/git/plutosdr-fw/buildroot/output/host/bin/mkpasswd -m "sha-256" "analog"`":, /mnt/d/git/plutosdr-fw/buildroot/output/target/etc/shadow
grep -qsE '^/bin/sh$' /mnt/d/git/plutosdr-fw/buildroot/output/target/etc/shells || echo "/bin/sh" >> /mnt/d/git/plutosdr-fw/buildroot/output/target/etc/shells
if [ -x /mnt/d/git/plutosdr-fw/buildroot/output/target/sbin/swapon -a -x /mnt/d/git/plutosdr-fw/buildroot/output/target/sbin/swapoff ]; then /bin/sed -i -e '/^#.*\/sbin\/swap/s/^#\+[[:blank:]]*//' /mnt/d/git/plutosdr-fw/buildroot/output/target/etc/inittab; else /bin/sed -i -e '/^[^#].*\/sbin\/swap/s/^/#/' /mnt/d/git/plutosdr-fw/buildroot/output/target/etc/inittab; fi
printf '%s\n' C en_US locale-archive > /mnt/d/git/plutosdr-fw/buildroot/output/build/locales.nopurge
for dir in /mnt/d/git/plutosdr-fw/buildroot/output/target/usr/share/locale /mnt/d/git/plutosdr-fw/buildroot/output/target/usr/share/X11/locale /mnt/d/git/plutosdr-fw/buildroot/output/target/usr/lib/locale; do if [ ! -d $dir ]; then continue; fi; for langdir in $dir/*; do if [ -e "${langdir}" ]; then grep -qx "${langdir##*/}" /mnt/d/git/plutosdr-fw/buildroot/output/build/locales.nopurge || rm -rf $langdir; fi done; done
if [ -d /mnt/d/git/plutosdr-fw/buildroot/output/target/usr/share/X11/locale ]; then for lang in C en_US; do if [ -f /mnt/d/git/plutosdr-fw/buildroot/output/target/usr/share/X11/locale/$lang/XLC_LOCALE ]; then echo "$lang/XLC_LOCALE: $lang"; fi done > /mnt/d/git/plutosdr-fw/buildroot/output/target/usr/share/X11/locale/locale.dir; fi
rm -rf /mnt/d/git/plutosdr-fw/buildroot/output/target/usr/include /mnt/d/git/plutosdr-fw/buildroot/output/target/usr/share/aclocal \
        /mnt/d/git/plutosdr-fw/buildroot/output/target/usr/lib/pkgconfig /mnt/d/git/plutosdr-fw/buildroot/output/target/usr/share/pkgconfig \
        /mnt/d/git/plutosdr-fw/buildroot/output/target/usr/lib/cmake /mnt/d/git/plutosdr-fw/buildroot/output/target/usr/share/cmake \
        /mnt/d/git/plutosdr-fw/buildroot/output/target/usr/doc
find /mnt/d/git/plutosdr-fw/buildroot/output/target/usr/{lib,share}/ -name '*.cmake' -print0 | xargs -0 rm -f
find /mnt/d/git/plutosdr-fw/buildroot/output/target/lib/ /mnt/d/git/plutosdr-fw/buildroot/output/target/usr/lib/ /mnt/d/git/plutosdr-fw/buildroot/output/target/usr/libexec/ \
        \( -name '*.a' -o -name '*.la' -o -name '*.prl' \) -print0 | xargs -0 rm -f
rm -rf /mnt/d/git/plutosdr-fw/buildroot/output/target/usr/share/gdb
rm -rf /mnt/d/git/plutosdr-fw/buildroot/output/target/usr/share/bash-completion
rm -rf /mnt/d/git/plutosdr-fw/buildroot/output/target/etc/bash_completion.d
rm -rf /mnt/d/git/plutosdr-fw/buildroot/output/target/usr/share/zsh
rm -rf /mnt/d/git/plutosdr-fw/buildroot/output/target/usr/man /mnt/d/git/plutosdr-fw/buildroot/output/target/usr/share/man
rm -rf /mnt/d/git/plutosdr-fw/buildroot/output/target/usr/info /mnt/d/git/plutosdr-fw/buildroot/output/target/usr/share/info
rm -rf /mnt/d/git/plutosdr-fw/buildroot/output/target/usr/doc /mnt/d/git/plutosdr-fw/buildroot/output/target/usr/share/doc
rm -rf /mnt/d/git/plutosdr-fw/buildroot/output/target/usr/share/gtk-doc
rmdir /mnt/d/git/plutosdr-fw/buildroot/output/target/usr/share 2>/dev/null || true
rm -rf /mnt/d/git/plutosdr-fw/buildroot/output/target/lib/debug /mnt/d/git/plutosdr-fw/buildroot/output/target/usr/lib/debug
find /mnt/d/git/plutosdr-fw/buildroot/output/target   -type f \( -perm /111 -o -name '*.so*' \) -not \( -name 'libpthread*.so*' -o -name 'ld-*.so*' -o -name '*.ko' \) -print0 | xargs -0 /mnt/d/git/plutosdr-fw/buildroot/output/host/bin/arm-linux-gnueabihf-strip --remove-section=.comment --remove-section=.note 2>/dev/null || true
find /mnt/d/git/plutosdr-fw/buildroot/output/target   \( -name 'ld-*.so*' -o -name 'libpthread*.so*' \) -print0 | xargs -0 -r /mnt/d/git/plutosdr-fw/buildroot/output/host/bin/arm-linux-gnueabihf-strip --remove-section=.comment --remove-section=.note --strip-debug 2>/dev/null || true
test -f /mnt/d/git/plutosdr-fw/buildroot/output/target/etc/ld.so.conf && \
        { echo "ERROR: we shouldn't have a /etc/ld.so.conf file"; exit 1; } || true
ERROR: we shouldn't have a /etc/ld.so.conf file
make[1]: *** [Makefile:750: target-finalize] Error 1
make[1]: Leaving directory '/mnt/d/git/plutosdr-fw/buildroot'
make: *** [Makefile:124: buildroot/output/images/rootfs.cpio.gz] Error 2

The file ld.so.conf in output/target/etc should not exist http://lists.busybox.net/pipermail/buildroot/2016-January/148854.html

but it is there and has the following content:

include /etc/ld.so.conf.d/*.conf

Edit: At it looks like the file comes from /tools/Xilinx/Vitis/2022.1/gnu/aarch32/lin/gcc-arm-linux-gnueabi/cortexa9t2hf-neon-xilinx-linux-gnueabi/etc. We have to prevent somehow that its getting copied from there. @nunojsa @mhennerich do You have an idea how to do that? Patch buildroot? Delete the file in Vitis?

I think we can disable this check in ADI buildroot, since there is no easy way to add a hook to custom external toolchain that could delete this file.

catkira commented 2 years ago

World premiere, finally rootfs.cpio.gz can be created with Vitis 2022.1 📦 

make[1]: Leaving directory '/mnt/d/git/plutosdr-fw/buildroot'
cp buildroot/output/images/rootfs.cpio.gz build/rootfs.cpio.gz
cp build/rootfs.cpio.gz rootfs.cpio.gz

I have documented all the necessary changes in the README file of this PR.

mhennerich commented 11 months ago

Let's close this now

https://github.com/analogdevicesinc/plutosdr-fw/commit/ea3d810769739ccd436e9cbb3cf5a227272b91a2

Makefile: Switch to buildroot Linaro toolchain

Due to incompatibility between the AMD/Xilinx GCC toolchain supplied with Vivado/Vitis and Buildroot. This project switched to Buildroot external Toolchain: Linaro GCC 7.3-2018.05 7.3.1

https://releases.linaro.org/components/toolchain/binaries/7.3-2018.05/arm-linux-gnueabihf/

This toolchain is used to build: Buildroot, Linux and u-boot