On Thu, Feb 10, 2022 at 5:07 PM Stefano Stabellini stefano.stabellini@xilinx.com wrote:
On Thu, 10 Feb 2022, Grant Likely wrote:
On Thu, Feb 10, 2022 at 8:44 AM Grant Likely grant.likely@linaro.org wrote:
Bill, Can you expand on the objection to increasing #address-cells? Historically it has been common practice to add address space information by prepending another cell to encode it. e.g., the PCI bindings. Has that approach been causing problems?
Thanks, g.
On 9 Feb 2022, at 21:27, Stefano Stabellini via System-dt system-dt@lists.openampproject.org wrote:
Hi Bill,
I'll reply here also to the other email on the subject ("Dual core MCU with secure and non-secure views of one bus").
To provide context to the others on the mailing list, yesterday during the system device tree meeting we discussed how to express devices with different secure and non-secure addresses. See attached slides.
The proposal is to use:
- a new bus type compatible "secure-bus"
- the first address cell in "reg" of each device under secure-bus
expresses the address type (secure vs non-secure)
- the first address cell in "ranges" is the address type
Example:
amba { compatible = "secure-bus"; #address-cells = <0x2>; #size-cells = <0x1>; /* non-secure mapping */ ranges = <0x0 0xff110000 0xff110000 0x1000 /* secure mapping */ 0x1 0xc0110000 0xc0110000 0x1000>;
timer0: timer@ff110000 { compatible = "cdns,ttc"; status = "okay"; /* non-secure addresses */ reg = <0x0 0xff110000 0x1000 /* secure addresses */ 0x1 0xc0110000 0x1000> };Bill pointed out that it is common to have all devices shifted by an offset when accessed secure vs non-secure. So it would be nice to be able to do that without having to write two address ranges in "reg" for every single device.
Maybe we could find a way to let the devices under a secure-bus have a single range of addresses (no address type cell) but still have the address type cell in the "ranges" property so that we can do the mapping in a single place at the bus level.
Example:
amba { compatible = "secure-bus"; #address-cells = <0x2>; #size-cells = <0x1>; /* non-secure mapping */ ranges = <0x0 0xff110000 0xff110000 0x1000 /* secure mapping */ 0x1 0xff110000 0xc0110000 0x1000>;
timer0: timer@ff110000 { compatible = "cdns,ttc"; status = "okay"; reg = <0xff110000 0x1000>; };The nice bit about this is that all the device descriptions are unmodified (timer0 and everything else under amba). Under amba we need just one more mapping in "ranges" to make it work.
The problem with this is that it is not correct from a device tree point of view: #address-cells under amba tell us how many address cells to use to express the address and should apply not just to ranges but also to all children. I am not sure if there is a simple way around to this, with or without introducing something like #space-cells.
Yeah, that does not look good. It breaks any existing assumptions about how reg and ranges gets interpreted.
However, can the address space get encoded into the parent node? e.g. ranges = <0xff110000 0x0 0xff110000 0x1000>, <0xff110000 0x1 0xc0110000 0x1000>? That would be the clean way to map devices to different places, and lopper would have a simplified way to transform the system description to specific views of the system without having to touch every node. If changing the #address-cells size of the parent bus isn't reasonable, then an interposer node could be used to manage the translation. e.g.:
{ #address-cells = <1>; secure-bus-interposer { #address-cells = <2>; // No ranges yet? Or a simplified ranges that lopper would modify? ranges = <0 0xff110000 0xff110000 0x1000>, <0x1 0xc0110000 0xc0110000 0x1000>; amba { #address-cells = <1>; ranges = <0xff110000 0 0xff110000 0x1000>, <0xff110000 0x1 0xc0110000 0x1000>; timer@ff110000 { reg = <0xff110000 0x1000>; } ; }; }; };
This would work, and also changing #address-cells of the parent node I think would work.
How can we tell whether #address-cells = <2> means 64-bit addresses or secure/non-secure + 32-bit addresses?
Or #address-cells has to be set to <3> if we want the extra address-type cell?
Generally the meaning of the extra cell is defined by the 'compatible' value. In this case the interposer node has #address-cells going from 1 to 2 back to 1. On a 64 bit system it would go from 2 to 3 and back to 2. A compatible value should be added to the interposer example above.
However, in one sense it doesn't actually matter. The secure bit is just another bit in a regularly laid out address space. The address translation parsing doesn't need to know what the extra cell is, it just needs to perform the regular transformation of an address value. You could set the interposer compatible value to 'simple-bus' and everything should just work... assuming lopper doesn't need special knowledge to decide which ranges entries to keep/modify/drop.
g.