1*d9f43babSPeter Maydell* ARM Secure world bindings 2*d9f43babSPeter Maydell 3*d9f43babSPeter MaydellARM CPUs with TrustZone support have two distinct address spaces, 4*d9f43babSPeter Maydell"Normal" and "Secure". Most devicetree consumers (including the Linux 5*d9f43babSPeter Maydellkernel) are not TrustZone aware and run entirely in either the Normal 6*d9f43babSPeter Maydellworld or the Secure world. However some devicetree consumers are 7*d9f43babSPeter MaydellTrustZone aware and need to be able to determine whether devices are 8*d9f43babSPeter Maydellvisible only in the Secure address space, only in the Normal address 9*d9f43babSPeter Maydellspace, or visible in both. (One example of that situation would be a 10*d9f43babSPeter Maydellvirtual machine which boots Secure firmware and wants to tell the 11*d9f43babSPeter Maydellfirmware about the layout of the machine via devicetree.) 12*d9f43babSPeter Maydell 13*d9f43babSPeter MaydellThe general principle of the naming scheme for Secure world bindings 14*d9f43babSPeter Maydellis that any property that needs a different value in the Secure world 15*d9f43babSPeter Maydellcan be supported by prefixing the property name with "secure-". So for 16*d9f43babSPeter Maydellinstance "secure-foo" would override "foo". For property names with 17*d9f43babSPeter Maydella vendor prefix, the Secure variant of "vendor,foo" would be 18*d9f43babSPeter Maydell"vendor,secure-foo". If there is no "secure-" property then the Secure 19*d9f43babSPeter Maydellworld value is the same as specified for the Normal world by the 20*d9f43babSPeter Maydellnon-prefixed property. However, only the properties listed below may 21*d9f43babSPeter Maydellvalidly have "secure-" versions; this list will be enlarged on a 22*d9f43babSPeter Maydellcase-by-case basis. 23*d9f43babSPeter Maydell 24*d9f43babSPeter MaydellDefining the bindings in this way means that a device tree which has 25*d9f43babSPeter Maydellbeen annotated to indicate the presence of Secure-only devices can 26*d9f43babSPeter Maydellstill be processed unmodified by existing Non-secure software (and in 27*d9f43babSPeter Maydellparticular by the kernel). 28*d9f43babSPeter Maydell 29*d9f43babSPeter MaydellNote that it is still valid for bindings intended for purely Secure 30*d9f43babSPeter Maydellworld consumers (like kernels that run entirely in Secure) to simply 31*d9f43babSPeter Maydelldescribe the view of Secure world using the standard bindings. These 32*d9f43babSPeter Maydellsecure- bindings only need to be used where both the Secure and Normal 33*d9f43babSPeter Maydellworld views need to be described in a single device tree. 34*d9f43babSPeter Maydell 35*d9f43babSPeter MaydellValid Secure world properties: 36*d9f43babSPeter Maydell 37*d9f43babSPeter Maydell- secure-status : specifies whether the device is present and usable 38*d9f43babSPeter Maydell in the secure world. The combination of this with "status" allows 39*d9f43babSPeter Maydell the various possible combinations of device visibility to be 40*d9f43babSPeter Maydell specified. If "secure-status" is not specified it defaults to the 41*d9f43babSPeter Maydell same value as "status"; if "status" is not specified either then 42*d9f43babSPeter Maydell both default to "okay". This means the following combinations are 43*d9f43babSPeter Maydell possible: 44*d9f43babSPeter Maydell 45*d9f43babSPeter Maydell /* Neither specified: default to visible in both S and NS */ 46*d9f43babSPeter Maydell secure-status = "okay"; /* visible in both */ 47*d9f43babSPeter Maydell status = "okay"; /* visible in both */ 48*d9f43babSPeter Maydell status = "okay"; secure-status = "okay"; /* visible in both */ 49*d9f43babSPeter Maydell secure-status = "disabled"; /* NS-only */ 50*d9f43babSPeter Maydell status = "okay"; secure-status = "disabled"; /* NS-only */ 51*d9f43babSPeter Maydell status = "disabled"; secure-status = "okay"; /* S-only */ 52*d9f43babSPeter Maydell status = "disabled"; /* disabled in both */ 53*d9f43babSPeter Maydell status = "disabled"; secure-status = "disabled"; /* disabled in both */ 54