[Ground-station] can't find dt-bindings - embedded build for zcu102+ADRV9002 progress and current roadblock

Thu Jun 1 19:36:07 PDT 2023

Update! This is about Mathworks buildroot for Neptune. Some progress, new
blocker.

The missing header files (dt-bindings for the device tree) for the
zcu102-adrv9002 build go here:

abraxas3d at chococat:~/neptune/buildroot/output/zcu102_linux_linaro/build/linux-mathworks_zynq_R21.2.0/include/dt-bindings$
ls
arm  clock    dma  gpio  iio    interrupt-controller  media   mfd  phy
 power  regulator  soc    spmi
clk  display  drm  i2c   input  leds                  memory  net  pinctrl
 pwm    reset      sound  thermal

The above directory is the directory that is pointed to by this symbolic
link below:

abraxas3d at chococat:~/neptune/buildroot/output/zcu102_linux_linaro/build/linux-mathworks_zynq_R21.2.0/arch/arm64/boot/dts/include$
ls -l
total 0
lrwxrwxrwx 1 abraxas3d abraxas3d 34 Jul  1  2021 dt-bindings ->
../../../../../include/dt-bindings

So, this is where the additional header files, that are included in the
radio card device tree source files, need to go.

So, I downloaded all these header files from Analog Devices, hand copied
them over, and ran the build script build.py. The symbolic link is already
in there.

However, the build script overwrites that source directory. The radio card
header files go away. The directory contents after running the build script
are only the Xilinx dev board header files.

I read through the build script and the other helper scripts, looked at the
.mk files, looked at the defconfigs, config.in files, and grepped for
anything relating to setting up this directory to see where it was setting
up this directory and where it was cleaning it up.

Analog Devices said they could not help figure it out, since it's not their
codebase. They were helpful with some other things relating to transceiver
configuration, but we can't quite get there yet if we can't talk to the
card.

The Kuiper build from Analog Devices does things differently. You download
a pre-built card, and then move radio-centric files to particular
directories, including the compiled .dtb. For that version of embedded
linux, there's no building or compiling of anything at all.

Petalinux has a menu-config process. You put the .dts file in a particular
directory, point to it with a config file, and then it compiles the radio
card devices into the device tree.

I asked Mathworks for help. The build process is handled by a python script
that comes directly from the repository. The symbolic link and the
populating of the dt-bindings directory from source are handled somewhere
in all the build mechanisms.

Anyone have any clever way around this problem?

-Michelle Thompson

On Wed, May 24, 2023 at 7:43 PM Michelle Thompson <
mountain.michelle at gmail.com> wrote:

> Greetings all!
>
> We can produce an SD card image for the zcu102 (our FPGA development
> station in Remote Labs that serves Neptune, etc,) in several ways.
>
> 1) We have a working Analog Devices Kuiper build.
> 2) We know how to make a petalinux build (haven't produced one yet, but
> would follow the same process as we did for the zcu706+ADRV9371).
> 3) We are trying to produce a mathworks buildroot build so we can use HDL
> Coder (MATLAB/Simulink).
>
> Getting to the point where a zcu102 SD image was produced required
> installing some missing packages on Chococat and applying some patches. One
> patch we found on the internet and the other we created from the commit
> number. We had to add in a symbolic link so that /opt/Xilinx could be found
> (for the Vivado SDK) because we have our tools in /tools/Xilinx at Remote
> Labs.
>
> We're at the point where we are trying to compile the device tree for the
> zcu102-adrv9002. In other words, we want to add the SDR device tree to the
> embedded linux image in order to be able to connect to the radio with IIO
> from MATLAB and use HDL Coder with minimum friction.
>
> We have the .dts (Device Tree Source) file from Analog Devices github for
> the ADRV9002. This file includes several other .dts files. We copied all of
> those to the dts directory successfully.
>
> We exported a new psu_init_gpl.c and psu_init_gpl.h from Vivado, using the
> reference design from Analog Devices of the zcu102-adrv9002 combination, as
> laid out in the "handoff files" part of the directions here:
> https://www.mathworks.com/help/hdlcoder/ug/xilinx-zynq-linux-image-for-custom-boards.html
>
> The instructions in the link above are for adding a completely new custom
> FPGA dev board to buildroot, and not for the (easier? maybe?) case of
> adding a supported radio card to a supported dev board.
>
> Adding a radio card to a supported dev board is what we're trying to do.
>
> I am hoping the workflow of adding a new development board and adding a
> supported radio card to a supported development board is the same or
> similar process.
>
> If you are reading this and can help, please speak up.I have not found a
> walkthrough or explanation or video on this yet. When we get it to work,
> we'll write one up.
>
> The exported .c and .h files were different from the ones that were
> already there in buildroot in /boards/zcu102/boot/handoff, and this isn't
> surprising. The ones already there only know about the zcu102. The new ones
> are from the export of the reference design that has both the zcu102 and
> the adrv9002 designs in it.
>
> We think that to include a new .dts file, we need to add values - shown
> below - to the defconfig file at this level. Note that the zcu102 defconfig
> does have a copy and paste typo in the comment header - it says ZC706
> (which is a different board), but the commands in the file before we added
> ours were correct. They all (correctly) referred to the zcu102. The top two
> commands were in the file when we found it. The bottom three commands are
> what we added.
>
> The file below is definitely defconfig from
> ~/neptune/buildroot/board/mathworks/zynqmp/boards/zcu102/defconfig.
>
> ###########################################
> # ZC706 Options
> ###########################################
> BR2_TARGET_UBOOT_BOARD_DEFCONFIG="xilinx_zynqmp_zcu102_rev1_0"
>
> BR2_PACKAGE_XILINX_BOOTLOADER_UBOOT_TARGET_DIR="board/xilinx/zynqmp/zynqmp-zcu102-rev1.0"
>
> BR2_LINUX_KERNEL_DTS_SUPPORT=y
> BR2_LINUX_KERNEL_USE_CUSTOM_DTS=y
> BR2_LINUX_KERNEL_CUSTOM_DTS_PATH="/home/abraxas3d/neptune/buildro....
> (multiple .dts files)
>
> This moved things forward quite a bit!
>
> But the build script errors out with a failure to find dt-bindings.
>
> Failing to find dt-bindings can be solved with a symbolic link, according
> to a couple of posts here and there from people having similar problems
> with trying to add custom .dts files to an existing device tree setup in a
> linux build, but I do not know where it was looking for dt-bindings in the
> first place, or where the "right" dt-bindings include files are. I'm not
> sure what to link to what.
>
> Here is the error message snippet and the build log attached:
>
> In file included from arch/arm64/boot/dts/zynqmp-zcu102-revA.dts:12:0,
>          from arch/arm64/boot/dts/zynqmp-zcu102-revB.dts:10,
>          from arch/arm64/boot/dts/zynqmp-zcu102-rev1.0.dts:10,
>          from arch/arm64/boot/dts/zynqmp-zcu102-rev10-adrv9002.dts:10:
> arch/arm64/boot/dts/zynqmp.dtsi:15:47: fatal error:
> dt-bindings/dma/xlnx-zynqmp-dpdma.h: No such file or directory
>  #include <dt-bindings/dma/xlnx-zynqmp-dpdma.h>
>                         ^
> compilation terminated.
> scripts/Makefile.lib:313: recipe for target
> 'arch/arm64/boot/dts/zynqmp-zcu102-rev10-adrv9002.dtb' failed
> make[3]: *** [arch/arm64/boot/dts/zynqmp-zcu102-rev10-adrv9002.dtb] Error 1
> arch/arm64/Makefile:114: recipe for target
> 'zynqmp-zcu102-rev10-adrv9002.dtb' failed
> make[2]: *** [zynqmp-zcu102-rev10-adrv9002.dtb] Error 2
> package/pkg-generic.mk:227: recipe for target
> '/home/abraxas3d/neptune/buildroot/output/zcu102_linux_linaro/build/linux-mathworks_zynq_R21.2.0/.stamp_built'
> failed
>
> We can look at the .dtb file produced by mathworks buildroot (before
> trying to add the ADRV9002 device files) with fdtdump and see all sorts of
> things that we expect - just no radio devices yet.
>
> Optimistic that it's close to working. If you can take a look at this
> build on Chococat and explain where the symbolic link needs to go, that
> would be a big help.
>
> Thanks everyone! We're also setting things up in Simulink for golden tests
> and some doppler experiments, so you should see some initial waveforms and
> test results shortly.
>
> If you want to join the team or just observe the engineering firsthand,
> please find #Neptune channel on our Slack.
>
> -Michelle Thompson
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openresearch.institute/pipermail/ground-station-openresearch.institute/attachments/20230602/5a870dea/attachment.htm>