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>; } ; }; }; };
In short, I think we need a way to say that we use two cells for "ranges" (first cell is the address type) and only one cell for "regs" in the children nodes (no address type cells).
Cheers,
Stefano
On Tue, 8 Feb 2022, Bill Mills wrote: Stefano,
If we do need ranges, regs, and address-maps to contain a "address space" identifier, then I purpose a #space-cells value. Expected values are 1 or 0 and assumed to be 0 where not specified. I think this resolves the ambiguity of meaning in address-cells between normal DT and system DT.
I am sure it is a bigger change to the tools and spec but adding 1 to address cells just seems like a hack.
Thanks, Bill
-- Bill Mills Principal Technical Consultant, Linaro +1-240-643-0836 TZ: US Eastern Work Schedule: Tues/Wed/Thur
-- System-dt mailing list -- system-dt@lists.openampproject.org To unsubscribe send an email to system-dt-leave@lists.openampproject.org