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.

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

Hi Grant,

Nice email address :)

On 2/10/22 5:40 AM, 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?

If there is strong precedent than my concern is less.

When we were discussing it, having address size change multiple times at various levels seemed to cause confusion. When does 2 mean 64 bit and when does it mean 32 with an address space. Your solution below keeps the changes close together at least.

My main concern is: make complex things possible but keep simple things simple.

It seems armv8m is _required_ to have different addresses for secure and non-secure. If true, then I think things like the below example will be common and should have a simple solution.

The other common situation is typical of most cortex-A devices. Secure and non secure have the same numerical address. Yes the secure bit is transported on the buses but it makes very little difference at the address level. It is a firewall, dynamically programed, that makes a reg range accessible or not. This allow/deny info goes into the domains nodes. We should not be adding the address space identifier in this case as that is a lot of churn for no gain.

Stefano's proposals do make the complex things possible so the end solution needs to keep some form of that flexibility. I just don't want to modify every reg property for one overly complex peripheral or uncommon SOC.

...

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

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.