linker: aarch32: automatic derivation of region names from devicetree nodes

[JordanYates]

Update the aarch32 linker file to automatically derive the name of memory regions from devicetree nodes instead of providing hardcoded values. This is required for automatic generation of regions based on compatibles, and also allows chosen and alias nodes to be used to control variable placement (as desired in #36152).

Board and SoC updates were performed automatically via regex find and replace.

[henrikbrixandersen]

Why add labels instead of just using the DTS nodelabel?

[JordanYates]

Why add labels instead of just using the DTS nodelabel?

That is the alternate option, but:

1. There is currently no devicetree API to go from node to nodelabel.
2. Memory region names are typically UPPER_CASE, whereas node labels are lower_case.
3. Adding a label to all of these nodes is much less likely to be disruptive to other users than changing the nodelabel. A search on DT_NODELABEL(sram shows 36 hits already.

[JordanYates]

Actually I think the biggest problem is from https://docs.zephyrproject.org/latest/guides/dts/intro.html#syntax-and-structure

A node can have zero, one, or multiple node labels.

[erwango]

Actually I think the biggest problem is from https://docs.zephyrproject.org/latest/guides/dts/intro.html#syntax-and-structure

A node can have zero, one, or multiple node labels.

Is it?
Just like you're adding label prop, we can make sure that there is one label.
Then, I don't think having multiple node labels is an issue in our case.
Also, a major advantage for node labels being that they are unique, 2 nodes can't have same node label (checked by dts).

[JordanYates]

I am happy to transition to generating from the node labels if that is the generally preferred solution.
The remaining question is whether lower case region names are acceptable, or do they need to be upper-cased.

[erwango]

I am happy to transition to generating from the node labels if that is the generally preferred solution.

Thanks. I think that would indeed be preferred as in general we've tried to minimize their usage over the past years.

The remaining question is whether lower case region names are acceptable, or do they need to be upper-cased.

No preference on my part.
Maybe some have strong opinions on that though..

[JordanYates]

Are you aware of any syntax that lets you change or add another nodelabel to a node in an overlay? Apart from just deleting the node and creating it again?

[henrikbrixandersen]

Are you aware of any syntax that lets you change or add another nodelabel to a node in an overlay? Apart from just deleting the node and creating it again?

new_nodelabel: &existing_nodelabel {};

[JordanYates]

new_nodelabel: &existing_nodelabel {};

Cheers. Interestingly it looks like doing this in overlays always results in new_nodelabel being after existing_nodelabel in node.lables in python. Assuming that the solution will just use index 0 to generate a region name, it won't be possible to change the name in an overlay without changing some edtlib parsing.

[erwango]

Cheers. Interestingly it looks like doing this in overlays always results in new_nodelabel being after existing_nodelabel in node.lables in python. Assuming that the solution will just use index 0 to generate a region name, it won't be possible to change the name in an overlay without changing some edtlib parsing.

@mbolivar-nordic Is that expected ?

[JordanYates]

An overlay of

test1: &sram0 {};
test2: &sram0 {};

Will result in a zephyr.dts of

	sram0: test1: test2: memory@24000000 {

So it makes sense that the python labels have the order they do.
I feel like overlays should be able to override the name of the memory region, so I will look into the easiest way of just selecting the last property in a list.

[JordanYates]

Superseded by #36365

[mbolivar-nordic]

I haven't been following the discussion, but arbitrarily picking a node label as a canonical way to identify a node does not sound like a good approach. I will check #36365.