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.
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