Address mapping formulas

[mbolivar-nordic]

As of 4fc81d4, the specification
semantics for address-map properties is still not 100% clear to me
when I try to implement it.

I think it would be really good for the specification to include some
formulas or pseudo-code that says the exact way to translate a node's
register blocks to the CPU cluster address space, including a formula
for deciding whether a node is visible to the address map based on
register range overlaps.

This relates to the issue about whether we need a rule requiring
explicit address map translation via ranges properties for any nodes
we want to map in that aren't a child of the root.

[sstabellini]

The address-map transformation works similarly to ranges.

Let's say that the address range of an "amba" indirect-bus is 0xf000000-0xff000000 after ranges transformations.
Also let's say that we have:

                                         destination link source size
	address-map = <0x110000 &amba 0xf0110000 0x10000>;

The source of the mapping, which is the address of the amba bus the range 0xf0110000-0xf0120000. It is a subset of the original amba bus range (0xf000000-0xff000000) but it is still valid.

The range 0xf0110000-0xf0120000 becomes 0x110000-0x120000 for the cpu cluster.

• match "source" with the address of the node at "link"
• transform "source" into "destination" and also account for "size

[mbolivar-nordic]

@sstabellini thanks. In the meantime I went and tried to understand ranges better, especially the behavior of the length field in ranges, and partial ranges that don't map in all the registers of child nodes.

The precise details are missing from the devicetree specification and it took me a while to figure things out, but I think I get the basic "ranges" behavior now (and found at least one bug in Zephyr's handling of reg/ranges warnings along the way).

I'm still not clear on this issue, though, sorry:

Let's say that the address range of an "amba" indirect-bus is 0xf000000-0xff000000 after ranges transformations.

What do you mean by the address range after ranges transformations?

DT spec requires that "simple-bus" have a ranges property, so a /soc node with compatible simple-bus will have the obvious address translations to the root node's address space.

But "indirect-bus" has no such requirement, so it's not clear what this means to me in a case like this one:

lopper/specification/source/system-device-tree.dts

Line 222 in 395f00d

amba_rpu: rpu-bus {

I don't see a meaningful address range for /rpu-bus in this case.

What am I missing here?

[sstabellini]

Hi Marti,
In the example you linked, there should have been an empty ranges property like:

ranges;

which means that all addresses are 1:1 mapped to the parent address space.

By "Let's say that the address range of an "amba" indirect-bus is 0xf000000-0xff000000 after ranges transformations" I meant that the address range of amba is 0xf000000-0xff000000 after ranges transformation, in case there is a meaningful ranges property, or as-is (1:1) if there is an empty ranges property.

[sstabellini]

It is still a ranges transformation in my mental model, even if the transformation is 1:1 (no changes).

[mbolivar-nordic]

It is still a ranges transformation in my mental model, even if the transformation is 1:1 (no changes).

So does that mean that we should require ranges in an indirect-bus node?

[sstabellini]

Yes

[mbolivar-nordic]

OK, then I would like to revisit #167. Given the context here, it seems that an indirect-bus must always be a child of the root node, since you're saying that the relationship between the CPU cluster's address space and the indirect-bus's address space is established explicitly via a ranges property translating the indirect-bus node's address space to the root's.

[mbolivar-nordic]

Or, if not that, then at least there's a requirement that there be "ranges all the way down" to an indirect-bus that is not a direct child of the root.

[sstabellini]

Yes there should be "ranges all the way down", well spotted