On Wed, Jan 22, 2020 at 8:35 AM Driscoll, Dan dan_driscoll@mentor.com wrote:

Not sure if this will help and I know this is quite verbose, but, from what I see, we are converging on things that make sense to us at Mentor given our focus in this area.

We have been using a device tree based approach to system partitioning for the last 3-4 years and here are some points we have learned:

    *  To separate what we call the "system definition" (ie resource partitioning) from the hardware description, we have what we called a "System Definition Tree" or SDT file (found it kind of funny that SDT was also chosen for System Device Tree)
            * The SDT is a separate file that uses device tree syntax, but does NOT describe hardware, but rather sub-systems / partitioning using the hardware definition found in the DTS
            * The SDT file #includes the hardware description (ie top-level DTS file) and references nodes from this DT, so this keeps the 2 clearly separated (system definition versus hardware definition)

Do you have any public examples of this? Might be helpful.

Regarding the separation, How do you really separate the config and h/w desc? The h/w desc already has some amount of configuration in it and the tooling has to be aware of what h/w can be configured. Take for example, you want to assign cpus to domains (openamp domain or execution context in this use). You can make this link in either direction:

domain to cpu:

domain0: domain-cfg { assigned-cpus = <&cpu0>; };

cpu to domain:

&cpu0 { assigned-domain = <&domain0>; };

There's no difference in complexity to generate either one and both ways are separate from the h/w description at the source level. The primary difference is the separation in the final built DT. Does that matter? If so, then you'd pick the first method. However, we already have things in h/w description that you may want to configure. For example, flow control support for a UART which already has a defined way to configure it (a property in the uart node). So both ways are probably going to have to be supported.

Rob