Errors with Mathworks buildroot image compilation

I'm using the build.py script from the Mathworks buildroot repository at https://github.com/mathworks/buildroot

I'm running the following commands:

./build.py -b zc706 -p zynq

./build.py -b zcu102 -p zynqmp

Since we want to use MATLAB with the zcu102 station, we'll focus on that one.

The first problem was a missing locale.h.

It looks like the custom glibc (so that Simulink will run on Ubuntu 18.04) is preventing buildroot from finding locale.h

Those instructions can be found here: https://github.com/mathworks/build-glibc-bz-19329-patch

Fortunately we had another Ubuntu 18.04 machine without the custom glibc, so we moved over there.

We use Ubuntu 18.04 because we're using Vivado 2020.2. Ubuntu 20.04 and later do not officially support Vivado.

Vivado 2020.2 has been successfully tested with MATLAB 2022b and HDL Coder. Using HDL Coder is the goal.

After moving away from the custom glibc required to run Simulink, we got another error. It is below:

Cannot execute cross-compiler '/opt/linaro/aarch32-6.3.1-2017.02/bin/arm-linux-gnueabihf-gcc'

package/pkg-generic.mk:217: recipe for target '/home/abraxas3d/haifuraiya/buildroot/output/zc706_linux_linaro/build/toolchain-external-custom/.stamp_configured' failed

make[1]: *** [/home/abraxas3d/haifuraiya/buildroot/output/zc706_linux_linaro/build/toolchain-external-custom/.stamp_configured] Error 1

Makefile:16: recipe for target '_all' failed

make: *** [_all] Error 2

Uncaught exception

Traceback (most recent call last):

File "./build.py", line 191, in <module>

build_target(args, catalog)

File "./build.py", line 89, in build_target

subproc(argStr, cwd=args['outputDir'])

File "/home/abraxas3d/haifuraiya/buildroot/board/mathworks/common/scripts/helper_func.py", line 492, in subproc

_SUBPROC_LOGGER.call(args, cwd=cwd, shell=shell)

File "/home/abraxas3d/haifuraiya/buildroot/board/mathworks/common/scripts/helper_func.py", line 77, in call

raise subprocess.CalledProcessError(self.proc.returncode, self.strArgs(args), None)

CalledProcessError: Command 'make legal-info all' returned non-zero exit status 2

So, we couldn't execute the cross-compiler. The cross-compiler wasn't in this location, which appears to be hard-coded into build.py when you do not call out a custom location for the cross-compiler.

Installing the cross compilier from the package manager in Ubuntu, and pointing to it's location in usr/bin/ gave a different specific error, that package installations of a cross-compiler could not be used by buildroot.

This result conflicts with instructions on the Mathworks page here: https://www.mathworks.com/help/hdlcoder/ug/xilinx-zynq-linux-image-for-custom-boards.html. We think these instructions need to be updated.

Copying over files from the package install to opt/ did not work.

Finding the aarch32-6.3.1-2017.02 tarball from Linaro, and expanding it into opt/ and renaming the directories to match what build.py wanted got things much further along.

On Ubuntu 18.04, using the tag R22.2.0, and trying to build for the zc706, this build failed due to a problem with e2fsprogs.

./../misc/create_inode.c:395:18: error: conflicting types for 'copy_file_range'

static errcode_t copy_file_range(ext2_filsys fs, int fd, ext2_file_t e2_file,

^~~~~~~~~~~~~~~

In file included from ./../misc/create_inode.c:19:0:

/usr/include/unistd.h:1110:9: note: previous declaration of \u2018copy_file_range\u2019 was here

ssize_t copy_file_range (int __infd, __off64_t *__pinoff,

^~~~~~~~~~~~~~~

SUBST debugfs.8

Makefile:423: recipe for target 'create_inode.o' failed

make[4]: *** [create_inode.o] Error 1

make[4]: *** Waiting for unfinished jobs....

Makefile:405: recipe for target 'all-progs-recursive' failed

make[3]: *** [all-progs-recursive] Error 1

Makefile:340: recipe for target 'all' failed

make[2]: *** [all] Error 2

package/pkg-generic.mk:227: recipe for target '/home/abraxas3d/haifuraiya/buildroot/output/zc706_linux_linaro/build/host-e2fsprogs-1.43.4/.stamp_built' failed

make[1]: *** [/home/abraxas3d/haifuraiya/buildroot/output/zc706_linux_linaro/build/host-e2fsprogs-1.43.4/.stamp_built] Error 2

Makefile:16: recipe for target '_all' failed

make: *** [_all] Error 2

Uncaught exception

Traceback (most recent call last):

File "./build.py", line 191, in <module>

build_target(args, catalog)

File "./build.py", line 89, in build_target

subproc(argStr, cwd=args['outputDir'])

File "/home/abraxas3d/haifuraiya/buildroot/board/mathworks/common/scripts/helper_func.py", line 492, in subproc

_SUBPROC_LOGGER.call(args, cwd=cwd, shell=shell)

File "/home/abraxas3d/haifuraiya/buildroot/board/mathworks/common/scripts/helper_func.py", line 77, in call

raise subprocess.CalledProcessError(self.proc.returncode, self.strArgs(args), None)

CalledProcessError: Command 'make legal-info all' returned non-zero exit status 2

The tagged branch in the repository calls out e2fsprogs version 1.43.4. However, this version of e2fsprogs has a function name collision. That is what the error: conflicting types for 'copy_file_range' is indicating. This was fixed in e2fsprogs version 1.43.8.

The next step was to modify e2fsprogs.mk file from mathworks/buildroot repository and attempt to build the SD Card image again.

I made the version change in the e2fsprogs.mk file and re-ran the build. Again, this is to get an SD card image for the zc706 that works with MATLAB/Simulink/HDL Coder.The hash file also had to be updated, so that the sha256 hash of the e2fsprogs download would pass checks. The hash in e2fsprogs.hash was updated from https://mirrors.edge.kernel.org/pub/linux/kernel/people/tytso/e2fsprogs/v1.43.8/sha256sums.asc

A better way to fix this is to apply a patch. Radu from Mathworks helped throughout and advised us where to find the specific patch file for this name collision in glib. Patch file from: https://github.com/enclustra-bsp/bsp-xilinx/issues/6

And this is how to patch it:

Create a .patch file and put it in the buildroot/package/e2fsprogs folder

https://github.com/tytso/e2fsprogs/commit/01551bdba16ab16512a01affe02ade32c41ede8a

At this point we changed to MATLAB 2021b because this is the version that Analog Devices Transceiver Toolbox was compatible with. This meant checking all the other toolchains for compatibility.

There's a list here: https://www.mathworks.com/matlabcentral/answers/518421-which-versions-of-xilinx-vivado-are-supported-with-which-release-of-hdl-coder

"MATLAB R2021b HDL Coder has been tested against Xilinx Vivado 2020.1"

We sourced this version of Vivado and proceeded.

However, from the Transceiver Toolbox github release page, we noticed:

v21.2.1 Version

Upgraded to support R2021b and significant cleanup of HDL infrastructure.

Supported Tool Versions:

• MATLAB R2021b
• Xilinx Vivado 2019.1
• 2019-R2 SD Card (Kuiper Linux)

So, which Vivado do we need to use? This makes a big difference. For example, which branch of the HDL Reference design do we use? Is 2019.1 compatible wtih HDL Coder?

"MATLAB R2020a has been tested against Xilinx Vivado 2019.1"

So, do we back off to R2020a? Or, will this break something else? We decided to stay with R2021b, but Transceiver Toolbox not being compatible with the Vivado that R2021b HDL Coder has been tested against seems like an obvious risk.

New error:

-- Check for working C compiler: /home/abraxas3d/haifuraiya/buildroot/output/zc706_linux_linaro/host/usr/bin/arm-linux-gnueabihf-gcc -- works

-- Detecting C compiler ABI info

-- Detecting C compiler ABI info - done

-- Detecting C compile features

-- Detecting C compile features - done

-- Found PkgConfig: /home/abraxas3d/haifuraiya/buildroot/output/zc706_linux_linaro/host/usr/bin/pkg-config (found version "0.28")

-- Detected version of GNU GCC: 63 (603)

-- Looking for ccache - found (/usr/bin/ccache)

CMake Error at cmake/OpenCVCompilerOptions.cmake:21 (else):

A duplicate ELSE command was found inside an IF block.

Call Stack (most recent call first):

CMakeLists.txt:432 (include)

-- Configuring incomplete, errors occurred!

See also "/home/abraxas3d/haifuraiya/buildroot/output/zc706_linux_linaro/build/opencv-2.4.13.2/CMakeFiles/CMakeOutput.log".

package/pkg-generic.mk:217: recipe for target '/home/abraxas3d/haifuraiya/buildroot/output/zc706_linux_linaro/build/opencv-2.4.13.2/.stamp_configured' failed

make[1]: *** [/home/abraxas3d/haifuraiya/buildroot/output/zc706_linux_linaro/build/opencv-2.4.13.2/.stamp_configured] Error 1

Makefile:16: recipe for target '_all' failed

make: *** [_all] Error 2

Uncaught exception

Traceback (most recent call last):

File "./build.py", line 191, in <module>

build_target(args, catalog)

File "./build.py", line 89, in build_target

subproc(argStr, cwd=args['outputDir'])

File "/home/abraxas3d/haifuraiya/buildroot/board/mathworks/common/scripts/helper_func.py", line 492, in subproc

_SUBPROC_LOGGER.call(args, cwd=cwd, shell=shell)

File "/home/abraxas3d/haifuraiya/buildroot/board/mathworks/common/scripts/helper_func.py", line 77, in call

raise subprocess.CalledProcessError(self.proc.returncode, self.strArgs(args), None)

CalledProcessError: Command 'make legal-info all' returned non-zero exit status 2

Zeroing in on the error message:

-- Found PkgConfig: /home/abraxas3d/haifuraiya/buildroot/output/zc706_linux_linaro/host/usr/bin/pkg-config (found version "0.28")

-- Detected version of GNU GCC: 63 (603)

-- Looking for ccache - found (/usr/bin/ccache)

CMake Error at cmake/OpenCVCompilerOptions.cmake:21 (else):

A duplicate ELSE command was found inside an IF block.

Call Stack (most recent call first):

CMakeLists.txt:432 (include)

This seems to be related to a bug reported here:

https://github.com/opencv/opencv/issues/9584

#9584 OpenCV 2.4.13.3 failed to build: A duplicate ELSE command was found inside an IF block.

System information (version)• OpenCV => 2.4.13.3

• Operating System / Platform => ArchLinux 64-bit

• Compiler => gcc 7.1.1 with ccache 3.3.4 installed

Detailed descriptionOnce I run cmake, it produced the following error.

-- Found PkgConfig: /usr/local/bin/pkg-config (found version "0.29.2")

-- Looking for ccache - found (/usr/local/bin/ccache)

CMake Error at cmake/OpenCVCompilerOptions.cmake:21 (else):

"Fixed in 2.4 and master branch"

As far as I can tell, this fix was supposed to be backported to version 2.4.

According to the opencv.mk file, we have OPENCV_VERSION = 2.4.13.2

OpenCV => 2.4.13.3 was the version mentioned in the github issue about the misplaced "else" command.

So, our OpenCV called in by Mathworks Buildroot could be too old to get that bug fix.

I edited the opencv.mk file to update the version of opencv, like I did for e2fsprogs.

The release page for OpenCV says this version is from 2014, so I'm somewhat concerned about how old this is. Not that there's anything wrong with old code. Mathworks buildroot is using a Linaro cross compiler for ARM from 2017. Overall, though, these sorts of errors in the current Matlab linux build for Zynq dev boards makes me really nervous. We're using Ubuntu 18.04 here because that's what Vivado will run on.I'm wondering if this repository ever been tested or used on Ubuntu 18.04?

I'm edited the OpenCV.hash file and rerun the build.

Checking what versions of OpenCV had this particular commit:

abraxas3d@chococat:~/Downloads/opencv$ git tag --contains 126de0cd95418811e302996161e03195bf7e631a

2.4.13.4

2.4.13.5

2.4.13.6

2.4.13.7

Going with 2.4.13.4

The commit ID above is the one that fixes the cmake error with misplaced else statement.

Downloaded 2.4.13.4 tarball from github (opencv)

abraxas3d@chococat:~/Downloads$ sha256sum opencv-2.4.13.4.tar.gz

f8abf1fcc2da3bb1deac8776f07b8390f871372e2a44dc355c765dd379194481 opencv-2.4.13.4.tar.gz

updated hash in opencv.hash with the locally generated hash.

next error is also in opencv

Hunk #1 succeeded at 409 (offset 5 lines).

patching file modules/ocl/src/matrix_operations.cpp

patching file modules/python/src2/cv2.cpp

Applying 0002-avoid-sysctl_h.patch using patch:

patching file modules/core/src/parallel.cpp

Reversed (or previously applied) patch detected! Skipping patch.

1 out of 1 hunk ignored -- saving rejects to file modules/core/src/parallel.cpp.rej

patching file modules/core/src/system.cpp

Hunk #1 FAILED at 163.

1 out of 1 hunk FAILED -- saving rejects to file modules/core/src/system.cpp.rej

patching file modules/highgui/src/cap_ffmpeg_impl.hpp

Reversed (or previously applied) patch detected! Skipping patch.

1 out of 1 hunk ignored -- saving rejects to file modules/highgui/src/cap_ffmpeg_impl.hpp.rej

package/pkg-generic.mk:191: recipe for target '/home/abraxas3d/haifuraiya/buildroot/output/zc706_linux_linaro/build/opencv-2.4.13.4/.stamp_patched' failed

make[1]: *** [/home/abraxas3d/haifuraiya/buildroot/output/zc706_linux_linaro/build/opencv-2.4.13.4/.stamp_patched] Error 1

Makefile:16: recipe for target '_all' failed

make: *** [_all] Error 2

Uncaught exception

Traceback (most recent call last):

File "./build.py", line 191, in <module>

build_target(args, catalog)

File "./build.py", line 89, in build_target

subproc(argStr, cwd=args['outputDir'])

File "/home/abraxas3d/haifuraiya/buildroot/board/mathworks/common/scripts/helper_func.py", line 492, in subproc

_SUBPROC_LOGGER.call(args, cwd=cwd, shell=shell)

File "/home/abraxas3d/haifuraiya/buildroot/board/mathworks/common/scripts/helper_func.py", line 77, in call

raise subprocess.CalledProcessError(self.proc.returncode, self.strArgs(args), None)

CalledProcessError: Command 'make legal-info all' returned non-zero exit status 2

We look at these rejection files to see what's going on.

abraxas3d@chococat:~/haifuraiya/buildroot/output/zc706_linux_linaro/build/opencv-2.4.13.4/modules/core/src$ cat parallel.cpp.rej

--- modules/core/src/parallel.cpp

+++ modules/core/src/parallel.cpp

@@ -56,7 +56,7 @@

#include <sys/types.h>

#if defined ANDROID

#include <sys/sysconf.h>

- #else

+ #elif defined __APPLE__

#include <sys/sysctl.h>

#endif

#endif

abraxas3d@chococat:~/haifuraiya/buildroot/output/zc706_linux_linaro/build/opencv-2.4.13.4/modules/core/src$ cat system.cpp.rej

--- modules/core/src/system.cpp

+++ modules/core/src/system.cpp

@@ -163,7 +163,7 @@ std::wstring GetTempFileNameWinRT(std::wstring prefix)

#include <sys/types.h>

#if defined ANDROID

#include <sys/sysconf.h>

-#else

+#elif defined __APPLE__

#include <sys/sysctl.h>

#endif

#endif

No idea why Android and Apple support being added would cause this buildroot fail. We need some help figuring this out.

same error with 2.4.13.5

same error with 2.4.13.6

same error with 2.4.13.7, which is the end of version 2.4 of OpenCV.

-=-=-=-=-=-=-=-=-=-

We switched to a third machine and installed Vivado 2020.2

This OS is an Ubuntu 20.04 (Vivado 2020.2 is listed as supported by Ubuntu 20.04) with the R21.2.0 branch of mathworks buildroot.

After manually installing the ARM Linaro cross compiler in /opt/linaro and renaming the directory to match the default in the build.py script, the following error happened:

freadahead.c: In function 'freadahead': freadahead.c:92:3: error: #error "Please port gnulib freadahead.c to your platform! Look at the definition of fflush, fread, ungetc on your system, then report this to bug-gnulib." 92 | #error "Please port gnulib freadahead.c to your platform! Look at the definition of fflush, fread, ungetc on your system, then report this to bug-gnulib." | ^~~~~ make[5]: *** [Makefile:1915: freadahead.o] Error 1 make[5]: *** Waiting for unfinished jobs.... CC fseeko.o fseeko.c: In function 'rpl_fseeko': fseeko.c:110:4: error: #error "Please port gnulib fseeko.c to your platform! Look at the code in fseeko.c, then report this to bug-gnulib." 110 | #error "Please port gnulib fseeko.c to your platform! Look at the code in fseeko.c, then report this to bug-gnulib." | ^~~~~ make[5]: *** [Makefile:1915: fseeko.o] Error 1 make[4]: *** [Makefile:1674: all] Error 2 make[3]: *** [Makefile:1572: all-recursive] Error 1 make[2]: *** [Makefile:1528: all] Error 2

We backed up and found that there was a patch for the "misplaced else" OpenCV errors. It's commit c2e28if in OpenCV version 2.4 and can be created by "git format-patch -1 c2e281f"

Find the commit here: https://github.com/opencv/opencv/commit/c2e281f8cf1600756d396ea4e969222931d704dc

With this patch, things moved forward.

Eventually an SD card image was created by using build.py. However it did not have a device tree for the ADRV9002.

We now needed to get the device tree for the ADRV9002 into Mathworks Buildroot linux and figure out how to compile it in.

In order to do this, the device tree source file from Analog Devices was obtained.

Find this file here: https://github.com/analogdevicesinc/linux/blob/master/arch/arm64/boot/dts/xilinx/zynqmp-zcu102-rev10-adrv9002.dts

Where does this file go?

It turns out it goes in .../buildroot/board/mathworks/zynqmp/boards/zcu102/dts/linux/arch/arm64/boot/dts/xilinx/zynqmp-zcu102-rev10-adrv9002.dts

A set of errors happened. There are files included in the .dts that were missing. Here's an example:

ERROR:root: In file included from arch/arm64/boot/dts/zynqmp-zcu102-revA.dts:12:0,

ERROR:root: from arch/arm64/boot/dts/zynqmp-zcu102-revB.dts:10,

ERROR:root: from arch/arm64/boot/dts/zynqmp-zcu102-rev1.0.dts:10,

ERROR:root: from arch/arm64/boot/dts/zynqmp-zcu102-rev10-adrv9002.dts:10:

ERROR:root: arch/arm64/boot/dts/zynqmp.dtsi:15:47: fatal error: dt-/dma/xlnx-zynqmp-dpdma.h: No such file or directory

ERROR:root: #include <dt-bindings/dma/xlnx-zynqmp-dpdma.h>

The missing files were tracked down from the Analog Devices github by following the error messages.

abraxas3d@chococat:~/neptune/buildroot/board/mathworks/zynqmp/boards/zcu102/dts$ ls

adi-adrv9002.dtsi axistream.dts dt-bindings zynqmp-clk-ccf.dtsi zynqmp-zcu102-rev1.0.dts

axilite.dts base.dtsi linux zynqmp.dtsi zynqmp-zcu102-revA.dts

axistream_64.dts dlhdl.dts uapi zynqmp-zcu102-rev10-adrv9002.dts zynqmp-zcu102-revB.dts

When all the files were gathered, build.py errored out in the following way:

ERROR:root: /home/abraxas3d/neptune/buildroot/configs/zynqmp_zcu102_dynconfig_defconfig:189:warning: override: reassigning to symbol BR2_LINUX_KERNEL_DTS_SUPPORT

{ echo "ERROR: we shouldn't have a /etc/ld.so.conf file"; exit 1; } || true

{ echo "ERROR: we shouldn't have a /etc/ld.so.conf.d directory"; exit 1; } || true

ERROR:root: board/mathworks/zynqmp/scripts/postbuild_common.sh: illegal option -- i

ERROR:root: devicetree_axilite.dtb: ERROR (phandle_references): Reference to non-existent node or label "clkc"

Here's where we were stopped. We're not sure how to fix this yet or what the error message is trying to tell us.

-Abraxas3d

[Noam Levine]

Which specific Analog Devices transceiver are you using? MathWorks "out-of-the-box" solutions for code generation cover only the AD9361 + ZCU706, or ZCU102. If you're using an AD9371, ADRV9002, or ADRV9009/8, then you'll need to use the Analog Device Transceiver Toolbox - available on MATLAB File Exchange, or through the MATLAB Add-on Explorer. More informaton is avaialble on the Analog Devices Wiki - https://wiki.analog.com/resources/tools-software/transceiver-toolbox.

Support for ADI's Transceiver Toolbox is handled through ADI's Engineer Zone Software Interface Tools forum.

[Michelle Thompson]

Thank you for replying to this thread.

Attempting to use the Transceiver Toolbox lead to an equally difficult situation.

The Transceiver Toolbox requires a particular version of the HDL Reference Design that Analog Device's Transceiver Evaluation Software does not support. We cannot use Transceiver Toolbox without either an older version of TES, or Transceiver Toolbox being updated. The "API Version" must match exactly, but you can't download the version of TES that matches the API Version that Transceiver Toolbox is compatible with, and Transceiver Toolbox doesn't seem to work if you update the HDL/Vivado/Petalinux to the "latest" version.

Therefore, we are back to trying to build Mathworks Buildroot to use HDL Coder for FPGA in the loop. Efforts to build Mathworks Buildroot version of linux have so far been unsuccessful. I'm updating the post above, today, with all the rest of the experiences. Please note this is simply trying to get Mathworks Buildroot to build on Ubuntu, and then incorporate the published device tree source. This is advanced work, but it shouldn't be this hard. Some of the instructions are simply incorrect.

We spoke with Mathworks and Analog Devices people at IMS2023 in San Diego, CA, USA in June 2023 multiple times, and had a call with Mathworks folks the week after IMS2023 to try and figure out how to use Mathworks Buildroot with Xilinx Dev Boards (and Analog Devices radios). These were very good discussions.

In order to use Transceiver Toolbox, the radio really does need to be in the device tree. IIO can't talk to the radio without it being in the device tree in linux. Transceiver Toolbox doesn't let you make an end run around getting a build of linux that includes the radio hardware devices. We tried it - Transceiver Toolbox simply cannot find any radio device to talk to without building a version of linux that has the hardware represented properly within in. Getting the device tree incorporated in Petalinux works for us (what we do to get things working for our dev boards is documented at https://github.com/OpenResearchInstitute/documents/blob/master/Remote_Labs/Working-With-FPGAs.md) , but we've been told that HDL Coder may not work with Petalinux - that we have to use Mathworks Buildroot. When asking for specfics from Mathworks folks, no one seems to know that this is true "for sure", so far. This of course worried us. If we can't get Mathworks Buildroot to produce an SD card image, then we can't use Transceiver Toolbox. We're dead in the water in that direction.

Is there something special about Mathworks Buildroot that is required to use all the features of HDL Coder, or not? If it just provides lib IIO, then we're better off using Petalinux, which we have a lot more experience with and we can build a working device tree. If Petalinux isn't compatible with HDL Coder, then we are dead in the water there too.

That's the status as of today.

-Abraxas3d