0

I have a Xilinx Block Design that incorporates an "AXI BRAM Controller" (a Xilinx IP Core that interfaces an AXI bus to a Block Memory Generator - the details of this probably aren't important).

enter image description here

The key thing, I think, is that the Xilinx tools automatically generate a file called components/plnx_workspace/device-tree/device-tree/pl.dtsi that contains the device-tree definition for this Core:

/* components/plnx_workspace/device-tree/device-tree/pl.dtsi */
&amba {
    #address-cells = <2>;
    #size-cells = <2>;

[snip]

    axi_bram_ctrl_1: axi_bram_ctrl@a0040000 {
        clock-names = "s_axi_aclk";
        clocks = <&zynqmp_clk 71>;
        compatible = "xlnx,axi-bram-ctrl-4.1";
        reg = <0x0 0xa0040000 0x0 0x2000>;
        xlnx,bram-addr-width = <0xb>;

[snip]
};

I also have a file, called project-spec/meta-user/recipes-bsp/device-tree/files/system-user.dtsi, that is assigned for users to modify, and is the last .dtsi that is processed by the compiler.

I wish to use this file to modify the axi_bram_ctrl_1 node to enable UIO:

/* project-spec/meta-user/recipes-bsp/device-tree/files/system-user.dtsi */

/include/ "system-conf.dtsi"

/ {
};

&axi_bram_ctrl_1 {
    compatible = "generic-uio";
};

My understanding, based on Device Tree Mysteries#Labels, is that:

Using a label for a node's path is commonly used to refer to a previously existing node for the purpose of modifying the value of one or more properties in that node. In this example, the reg property is modified. Note that the reference is placed at the top level of the .dts file, not within a node, because the reference is expanded to the full path.

This is what I believe I have done, but the Device Tree Compiler throws the following error:

Exception: subprocess.CalledProcessError: Command '['dtc', '-@', '-@', '-p', '0x1000', '-@', '-i',
    [snip lots of paths]
' returned non-zero exit status 1.

Subprocess output:
Error: build/tmp/work/xilinx_zcu208-xilinx-linux/device-tree/xilinx-v2023.1+gitAUTOINC+0bd6e466ba-r0/system-user.dtsi:173.1-17

    Label or path axi_bram_ctrl_1 not found

FATAL ERROR: Syntax error parsing input tree

This is confusing to me, because in the live tree, I can see:

$ dtc -f /proc/device-tree
/ {
        [snip]

        __symbols__ {
                [snip]
                axi_bram_ctrl_1 = "/axi/axi_bram_ctrl@a0040000";

        [snip]

        axi {
                [snip]

                axi_bram_ctrl@a0040000 {
                        xlnx,single-port-bram = <0x01>;
                        xlnx,memory-depth = <0x800>;
                        clock-names = "s_axi_aclk";
                        xlnx,bram-inst-mode = "EXTERNAL";

                        [snip]

I've seen quite a few examples of this syntax, and it all looks similar to what I'm doing here. What could be causing this to fail?

davidA
  • 12,528
  • 9
  • 64
  • 96
  • Aside, it occurs to me now that replacing the node might not be the wisest decision. I could copy/paste the definition from the earlier .dtsi and then add my customisation, but I'd prefer not to manually duplicate the information (especially offset and size) that is generated by the tools, in case it is changed in the Block Design. It won't propagate if I do this. I know about runtime device-tree overlays, but maybe there's a way to apply a modification to an existing node at compile time? – davidA Jul 28 '23 at 04:07
  • "*I also have a file ... is the last .dtsi that is processed by the compiler.*" -- A **.dtsi** file is meant to be *included* into the main **.dts** file by the *preprocessor*. What preprocessor are you using that requires that syntax you use rather than `#include "xxx.dtsi"`? To see your mistake perhaps you need to save & review the preprocessor output before the DT compiler spits out the error. "*This is confusing to me, because in the live tree, I can see: ...*" -- That implies you have an ordering problem in the source. – sawdust Jul 28 '23 at 04:22
  • I think the preprocessor is something built into Yocto/bitbake. I'll see if I can break into the bitbake task and work out what order it's processing the input files. Thanks for the idea. – davidA Jul 28 '23 at 04:33
  • You're using the correct DT syntax for including a **.dtsi** file. However the C syntax seems to be used more often in the Linux kernel (by a 100 to one ratio in arch/arm/boot/dts/ anyway). If you use the C syntax (i.e. `#include ...`), then a method to obtain the output from the C preprocessor with all the inserted lines from included files is mentioned in [this answer](https://stackoverflow.com/questions/50658326/device-tree-compiler-not-recognizes-c-syntax-for-include-files). Otherwise the DTC preprocessor is built-in, and there seems to be no option for obtaining intermediate output. – sawdust Jul 29 '23 at 01:15

0 Answers0