[...] > >> * A mechanism would be needed to pass an additional device tree. > >> > >> 2) Modify the standard device tree blob to include annotations or > >> modifications to describe which resources are secure or not. In this > >> case, secure software would use the single device tree to identify the > >> secure resources. The added information could be used by secure > >> software to trim the device tree before passing it. Alternatively, > >> the information could be passed on to non-secure software with the > >> expectation that it would honor the device security. It would be > >> crucial that any data added to the device tree adhere to existing > >> conventions or expectations. > > > > This approach assumes assumes that the secure and non-secure physical > > address spaces are identical bar some portions being masked out on the > > non-secure side. This is not necessarily the case. > > True, but I would guess this is the common case. In practically every system I can think of, the address spaces are essentially the same bar masking. However, if we're trying to model the architectural envelope, then the fact that a single DTB can't encode that needs some consideration in this matter. > > Architecturally the secure and non-secure physical address spaces are > > entiorely separate, and do not necessarily mirror each other. > > > > It's entirely valid for some devices/RAM to only exist in one of the > > address spaces (we typically see secure-only devices, but > > non-secure-only devices are also possible). It's also entirely valid for > > the same device to be mapped at different addresses in each address > > space (e.g. the same UART could be mapped at both S:0xffff0000 and also > > at NS:0xcccc0000 and nowhere else in either address space). > > > > So approach (2) does not fit the architecture generally. From what I > > recall of previous discussions, we eventually figured out that you > > either need separate trees or a higher level container to address the > > secure vs nonsecure split. > > Though there's no reason both approaches can't be supported. If the 2 > views are radically different, then use 2 DTs. If they are similar and > just a matter of partitioning, then you can fix up the DT before > passing to non-secure world (or even do this with a script offline > (i.e. 1 dts and 2 dtb's)). That sounds possible, yes. Mark. -- To unsubscribe from this list: send the line "unsubscribe devicetree-spec" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
