Meaning of an ampersand prefix in a device tree

From: http://developer.toradex.com/device-tree-customization

Nodes can be referenced using the ampersand (&) character and the label.

Overwriting properties

To overwrite a property, the node needs to be referenced using the ampersand character and the label. Later device tree entries overwrite earlier entries (the sequence order of entries is what matters, hence the include order matters). Typically the higher layers (e.g. carrier board device tree) overwrite the lower layers (e.g. SoC device tree) since the higher layers include the lower layers at the very beginning.

E.g. for USB controllers which are capable to be device or host (dual-role), one can overwrite the default mode explicitly using the dr_mode property:

&usbdev0 { dr_mode = "host"; }; 

I find the DT syntax rather confusing. The answer from Xofo is accurate but doesn't really cover all of the questions you asked.

What does it convey if a node has & as its prefix?

The ampersand is how you reference a label. A node has a name and it optionally has a label formatted as: label: name. Omit the colon if no label. You can reference a node for two reasons (that I can think of): 1) to override the definition of the node (often in another file) or 2) link a property of one node to another node.

A label is only needed if you want to reference the node elsewhere ... using the ampersand syntax. Put another way, if you want to reference a node somewhere, then ensure that it has a label and then reference the label with an ampersand prefix.

What is the necessity of separating them from root node, while they can be present in the root node itself?

A node that has a name (just not a label) defines a node in the hierarchy and therefore must be inside something that specifies a position in the hierarchy. It could be in a tree of node definitions -- i.e. root node. Or it could be inside a node reference since a node reference is associated with a node definition that is at some position in the hierarchy.

A reference node should be outside of the hierarchy. IDK whether it makes sense to have a reference node inside a reference node ... probably not.

Interestingly, the above example also has two root nodes, how is that possible?

Nodes (both definitions and references) overlay; adding new info and overwriting existing. In your example, the first root defines two properties (model and compatible) and the second root adds a sub-node (hdmi) to the root.

I'll show how this stuff is useful. You could define a node a and then modify a like this:

/ { a { x = "1"; }; }; / { a { x = "2"; }; }; 

Or you could do it this way:

/ { b: a { x = "1"; }; }; &b { x = "2"; }; 

This is a trivial example, but consider that names can be longer and the hierarchy can be deeper.

FYI: a node name is unique within the children of a node -- by definition! If there are blocks that use the same node name for multiple blocks in the context of the same parent node, then the blocks are merged. On the other hand, a label must be unique across every block/node. A duplicate label results in a build error.