Deciphering Device Tree

Linux Device Tree: Understanding how a reference to a deleted node works?

TL;DR version

The /delete-node/ mdio; directive is deleting the mdio node that was added in imx6ul-imx6ull-var-som.dtsi or imx6ul-imx6ull-var-dart.dtsi.

Full version

OP pointed to imx6ul-imx6ull-var-som-concerto-board.dtsi as the source of the fragment. That is included by the following:

• imx6ul-var-som-concerto-board.dtsi
• imx6ull-var-som-concerto-board.dtsi
• imx6ulz-var-som-concerto-board.dtsi

One of those is included by at least the following, according to their imx6ul, imx6ull, or imx6ulz prefix:

ims6ul:

• imx6ul-var-som-concerto-board-emmc-sd-card.dts
• imx6ul-var-som-concerto-board-emmc-wifi.dts
• imx6ul-var-som-concerto-board-nand-sd-card.dts
• imx6ul-var-som-concerto-board-nand-wifi.dts

imx6ull:

• imx6ull-var-som-concerto-board-emmc-sd-card.dts
• imx6ull-var-som-concerto-board-emmc-wifi.dts
• imx6ull-var-som-concerto-board-nand-sd-card.dts
• imx6ull-var-som-concerto-board-nand-wifi.dts

imx6ulz:

• imx6ulz-var-som-concerto-board-emmc-sd-card.dts
• imx6ulz-var-som-concerto-board-emmc-wifi.dts
• imx6ulz-var-som-concerto-board-nand-sd-card.dts
• imx6ulz-var-som-concerto-board-nand-wifi.dts

Those all include one of the following, according to their imx6ul, imx6ull, or imx6ulz prefix:

imx6ul:

• imx6ul-var-som.dtsi, which includes imx6ul-imx6ull-var-som.dtsi

imx6ull:

• imx6ull-var-som.dtsi, which includes imx6ul-imx6ull-var-som.dtsi

imx6ulz:

• imx6ulz-var-som.dtsi, which includes imx6ul-imx6ull-var-dart.dtsi

imx6ul-imx6ull-var-som.dtsi and imx6ul-imx6ull-var-dart.dtsi both contain this section:

&fec1 {
    pinctrl-names = "default";
    pinctrl-0 = <&pinctrl_enet1>, <&pinctrl_enet1_gpio>, <&pinctrl_enet1_mdio>;
    phy-mode = "rmii";
    phy-reset-gpios=<&gpio5 0 GPIO_ACTIVE_LOW>;
    phy-reset-duration=<100>;
    phy-handle = <ðphy0>;
    status = "okay";

    mdio {
        #address-cells = <1>;
        #size-cells = <0>;

        ethphy0: ethernet-phy@1 {
            compatible = "ethernet-phy-ieee802.3-c22";
            micrel,rmii-reference-clock-select-25-mhz;
            micrel,led-mode = <1>;
            clocks = <&rmii_ref_clk>;
            clock-names = "rmii-ref";
            reg = <1>;
        };
    };
};

That modifies the node referenced by &fec1 (which is defined in imx6ul.dtsi) and adds a sub-node called mdio. But the imx6ul-imx6ull-var-som-concerto-board.dtsi referred to by OP contains this section:

&fec1 {
    pinctrl-0 = <&pinctrl_enet1>, <&pinctrl_enet1_gpio>;
    /delete-node/ mdio;
};

That also modifies the node referenced &fec1. The /delete-node/ mdio; directive removes the mdio sub-node added earlier.

Effect of /delete-node/ in the device tree compiler

Deleting a node with /delete-node/ removes the node, any label attached to the node, any properties contained in the node, and recursively, any nodes contained within the node. If the node being deleted by /delete-node/ does not exist, then the directive is silently ignored.

If a node is deleted, any references to the node (or referenced to any label that was attached to the node) from elsewhere in the device tree source will no longer be valid, so the device tree compiler will produce an error "Reference to non-existent node or label" when compiling the source.

Effect of /delete-node/ in device tree overlays

The /delete-node/ directive only affects the source being compiled. If it is used in the source for a device tree overlay, the /delete-node/ directive will have no effect on the live device tree to which the overlay is applied. There is nothing in the compiled dtbo output to say that a node should be deleted from the live tree when the overlay is applied.

What about /delete-property/?

The /delete-property/ directive is similar to /delete-node/ except that it is for deleting a property and any label attached to the property.

DTS file explanation - aliases

In the aliases section of a DTS, we see entries of the format

property = &label;

Each of the entries consists of :

a. property -- A new property defined here.

b. &label -- Complete DTS path to the node referenced by the label.

It basically assigns the value of b to a. Henceforth, the long-name to the node identified by the label can be accessed using the shorthand property.

Note that the RHS of this assignment is using labels and NOT the short-names of the individual nodes. Just like a label in C code refers to an instruction on the line where it is defined, a label in DTS refers to the individual node (using its complete long path) that is defined on that line.

For example, considering the following DTS,

lxr.free-electrons.com/source/arch/powerpc/boot/dts/mpc8313erdb.dts

whose aliases section consists of the following :

 20         aliases {
 21                 ethernet0 = &enet0;
 22                 ethernet1 = &enet1;
 23                 serial0 = &serial0;
 24                 serial1 = &serial1;
 25                 pci0 = &pci0;
 26         };

The newly defined properties (LHS)

• ethernet0
• ethernet1
• serial0
• serial1
• pci0

refer to the corresponding labels (RHS)

• enet0
• enet1
• serial0
• serial1
• pci0

For example, the property ethernet0 is now set to "/soc8313@e0000000/ethernet@24000" i.e. the node defined on the line where the label enet0 is defined.

---

UPDATE :

1. Why are aliases defined ONLY for ethernet0, serial0 ... ?

   • Further down the line, the developer intends to access these nodes in the kernel source code. Once an alias is defined in the DTS, a handle to the node it is referring to is obtained by simply searching for it in the aliases section rather than searching for it in the entire DTS.

     Source: The function find_node_by_alias() in the Linux kernel source.

2. Why pci0 node in NOT under the soc8313 node?

   • On MPC8313, the PCI and DMA blocks are interfaced via the IO-Sequencer(IOS). Hence the special treatment as compared to the other blocks (ethernet, I2C, UART) that are connected directly to the system bus.

What does the variable and value of DP83867_RGMIIDCTL_2_25_NS in device tree correspond to?

What does the variable and value of DP83867_RGMIIDCTL_2_25_NS in device tree correspond to?

From https://elixir.bootlin.com/linux/latest/A/ident/DP83867_RGMIIDCTL_2_25_NS it corresponds to a macro with the value 0x8.

 #define    DP83867_RGMIIDCTL_2_25_NS   0x8

Yocto find the recipe or class that defines a task

I found that the datastore contains the filename for tasks as a VarFlag,
from a devpyshell

pydevshell> d.getVarFlags("do_create_yaml")

gives

{'filename': '.....yocto/sources/core/../meta-xilinx-tools/classes/xsctyaml.bbclass', 'lineno': '61', 'func': 1, 'task': 1, 'python': '1', 'deps':   ['do_prepare_recipe_sysroot']}

So for the example in my question the active definition for the do_create_yaml task is in xsctyaml.bbclass.

How to define a partition table for an e.MMC device in a device tree?

I may be wrong, however, I have never seen eMMC partitions being specified in device tree. The eMMC partitioning is generally part of some kind of flashing process. For example, build systems like buildroot and OpenEmbedded/Yocto can generate a compressed ext4 rootfs image and the files required for boot as per the SoC go in the first partition which generally tends to be FAT32. However, there is also distroboot, where there is only a single eMMC partition formatted as ext4 and the files required for boot are picked from /boot on that partition.

Depending on your setup and requirements, you can have either a separate step for formatting and partitioning the eMMC from bootloader or use something like genimage tool, which generates a single .img by taking a specification of your eMMC partitioning requirements. See genimage. The .img file can be used to flash the eMMC using the simple "dd" tool.

To use genimage, as part of Yocto build process, you would need meta-ptx layer.

Addendum: I forgot to add how to format from u-boot. You do not mention the exact device you are using, but the eMMC flashing process from something like u-boot is pretty much the same for all SoC's. For example, have a look here. If you are using barebox as bootloader, I assume it should be pretty much the same though I cannot say for sure, since I have never used barebox.

---

Related Topics