[Ground-station] can't find dt-bindings - embedded build for zcu102+ADRV9002 progress and current roadblock
Michelle Thompson
mountain.michelle at gmail.com
Fri Jun 2 13:59:06 PDT 2023
Thank you Jan et al for great advice. Here's the current blocker and how we
got here:
I ran the build.py script, let it fail, copied over all the Analog Devices
specific .dts and .dtsi files to the directory that the build.py script
grafts in with a symbolic link, and re-rain build.py with --update, which
turns off the "make clean".
This got past the missing header files problem.
We're now at the very end of the process, but there's a missing symbol in
what appears to be a mathworks .dts => .dtb file generation step.
Here's the snippet:
/home/abraxas3d/neptune/buildroot/output/zcu102_linux_linaro/host/usr/bin/mkimage
-A arm64 -T ramdisk \
-C none -d
/home/abraxas3d/neptune/buildroot/output/zcu102_linux_linaro/images/rootfs.cpio.gz
/home/abraxas3d/neptune/buildroot/output/zcu102_linux_linaro/images/rootfs.cpio.uboot
Image Name:
Created: Fri Jun 2 20:19:37 2023
Image Type: AArch64 Linux RAMDisk Image (uncompressed)
Data Size: 19834858 Bytes = 19369.98 KiB = 18.92 MiB
Load Address: 00000000
Entry Point: 00000000
>>> Executing post-image script
board/mathworks/common/scripts/postimage_common.py
*devicetree_axilite.dtb: ERROR (phandle_references): Reference to
non-existent node or label "clkc"*
>>> Starting on image zynqmpec
>>>> Sourcing SD card contents from
/home/abraxas3d/neptune/buildroot/board/mathworks/zynqmp/sdcard
>>>> Generating axilite dtb
Makefile:718: recipe for target 'target-post-image' failed
make[1]: *** [target-post-image] Error 1
Makefile:16: recipe for target '_all' failed
Looking at axilite.dts, the only line in there is an include for base.dtsi.
Looking at base.dtsi, four "mw" files are included along with a single
command line.
"clkc" shows up in one of these four files (zynqmp-mw-common.dtsi) which is
definitely in the mathworks repository and is in the right place in the
file structure for the build.
Here's the exact reference:
abraxas3d at chococat:~/neptune/buildroot/board/mathworks/zynqmp/boards/zcu102/dts$
cat
/home/abraxas3d/neptune/buildroot/board/mathworks/zynqmp/dts/zynqmp-mw-common.dtsi
| grep clkc
clocks = <&clkc 15>;
There are two branches of the repository where these files come from.
There's main and socfpga. The line appears in both files.
Since these are from mathworks (the mw is short for mathworks) and are in
the repository, I asked our contacts over there about this, but I'm not
optimistic.
I'm looking over all the versions and branches, but we were super careful
about this and there really aren't many choices. We could try the "socfpga"
branch for mathworks buildroot instead of the "main" and see what happens,
but that's more guessing and not solving.
Ideas and advice welcome and appreciated! :D
-Michelle Thompson
On Fri, Jun 2, 2023 at 2:36 AM Michelle Thompson <
mountain.michelle at gmail.com> wrote:
> 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/fa2bcb11/attachment-0001.htm>
More information about the Ground-Station
mailing list