Collectives™ on Stack Overflow

Find centralized, trusted content and collaborate around the technologies you use most.

Learn more about Collectives

Teams

Q&A for work

Connect and share knowledge within a single location that is structured and easy to search.

Learn more about Teams

Let's say we have this example devicetree:

I just want to know what mechanism ranges uses so that it gets properly mapped to the device nodes ( ethernet@0,0 , i2c@1,0 , flash@2,0 ).

Does it use:

"child's domain address" (red) or

"order of appearance" (violet)

to properly figure out mapping?

"Does it use: ... to properly figure out mapping?" -- Neither. The ordering of DT nodes is not significant and typically for esthetics, so "order of appearance" can be immediately ruled out. Looks like the "mechanism" could be the first value of reg property of each node is a memory index. BTW the actual mapping of a device's I/O memory is typically performed by each device driver. The omission of a valid base address and length in the reg properties is unusual. – sawdust Jan 24, 2022 at 23:48 At least I know that the order does not matter. range is a 3-tuple consisting of (a) address from the child node's perspective, (b) address from the parent node's perspective and (c) size of that segment of addresses. So I have two ideas... Consider the range 0 0 0x10100000 0x100000 - it's address from the child node's perspective is 0 0 . It could be mapped to A: Child node's name ethernet@0,0 (note the @0,0 ). But unlikely as I read somewhere that @0,0 part is not used at all. Is this true? B: It is possible that the initial part of reg = <0 0 0x100> i.e. 0 0 is used. – 71GA Jan 25, 2022 at 10:32 to properly figure out mapping?

The ordering of DT nodes is not significant and typically done for esthetics, so "order of appearance" can be immediately ruled out. See The order in which the device-tree text file is written, does it matter?

The range property is supposed to be a 3-tuple of <child-bus-address>, <parent-bus-address>, and <length> values.
However the #address-cells property (of external-bus) specifies that the (external bus) <address> value will consist of two <u32> values. This "double-length" is applied only to <child-bus-address>, while <parent-bus-address> is a single <u32> value per the #address-cells property of the parent node. The #size-cells property specifies that the <length> value will consist of a single <u32> value.
Therefore the rangle property will apparently in your example consist of "triplets" composed of 4 values, the first two for <child-bus-address>, the next for <parent-bus-address>, and the last for <length>.

The reg property is supposed to be a pairs of <address> and <length> values.
Since the external-bus #address-cells property specifies (and/or the default value is 2 anyway) that the <address> value will consist of two <u32> values , and the #size-cells property specifies that the <length> value will consist of a single <u32> value, the reg property will in your example consist of a "pair" composed of 3 values, the first two for <address> and the last for <length>.

Note that the DT Specification requires that the <address> in the reg property must match the "@<unit-address>" in the node name. The additional ",0" in the <unit-address> is what what you guessed, the later half of the <address> in each reg .

So the answer to your question would be the <child-bus-address>, which is related to the chip select value.
However, rather than cite the <unit-address> in the node name, the salient linkage "mechanism" in the device node is the <address> in the reg property.

Thanks for contributing an answer to Stack Overflow!

• Please be sure to answer the question . Provide details and share your research!

But avoid …

• Asking for help, clarification, or responding to other answers.
• Making statements based on opinion; back them up with references or personal experience.

To learn more, see our tips on writing great answers .