1*c66ec88fSEmmanuel Vadot* ARM Secure world bindings 2*c66ec88fSEmmanuel Vadot 3*c66ec88fSEmmanuel VadotARM CPUs with TrustZone support have two distinct address spaces, 4*c66ec88fSEmmanuel Vadot"Normal" and "Secure". Most devicetree consumers (including the Linux 5*c66ec88fSEmmanuel Vadotkernel) are not TrustZone aware and run entirely in either the Normal 6*c66ec88fSEmmanuel Vadotworld or the Secure world. However some devicetree consumers are 7*c66ec88fSEmmanuel VadotTrustZone aware and need to be able to determine whether devices are 8*c66ec88fSEmmanuel Vadotvisible only in the Secure address space, only in the Normal address 9*c66ec88fSEmmanuel Vadotspace, or visible in both. (One example of that situation would be a 10*c66ec88fSEmmanuel Vadotvirtual machine which boots Secure firmware and wants to tell the 11*c66ec88fSEmmanuel Vadotfirmware about the layout of the machine via devicetree.) 12*c66ec88fSEmmanuel Vadot 13*c66ec88fSEmmanuel VadotThe general principle of the naming scheme for Secure world bindings 14*c66ec88fSEmmanuel Vadotis that any property that needs a different value in the Secure world 15*c66ec88fSEmmanuel Vadotcan be supported by prefixing the property name with "secure-". So for 16*c66ec88fSEmmanuel Vadotinstance "secure-foo" would override "foo". For property names with 17*c66ec88fSEmmanuel Vadota vendor prefix, the Secure variant of "vendor,foo" would be 18*c66ec88fSEmmanuel Vadot"vendor,secure-foo". If there is no "secure-" property then the Secure 19*c66ec88fSEmmanuel Vadotworld value is the same as specified for the Normal world by the 20*c66ec88fSEmmanuel Vadotnon-prefixed property. However, only the properties listed below may 21*c66ec88fSEmmanuel Vadotvalidly have "secure-" versions; this list will be enlarged on a 22*c66ec88fSEmmanuel Vadotcase-by-case basis. 23*c66ec88fSEmmanuel Vadot 24*c66ec88fSEmmanuel VadotDefining the bindings in this way means that a device tree which has 25*c66ec88fSEmmanuel Vadotbeen annotated to indicate the presence of Secure-only devices can 26*c66ec88fSEmmanuel Vadotstill be processed unmodified by existing Non-secure software (and in 27*c66ec88fSEmmanuel Vadotparticular by the kernel). 28*c66ec88fSEmmanuel Vadot 29*c66ec88fSEmmanuel VadotNote that it is still valid for bindings intended for purely Secure 30*c66ec88fSEmmanuel Vadotworld consumers (like kernels that run entirely in Secure) to simply 31*c66ec88fSEmmanuel Vadotdescribe the view of Secure world using the standard bindings. These 32*c66ec88fSEmmanuel Vadotsecure- bindings only need to be used where both the Secure and Normal 33*c66ec88fSEmmanuel Vadotworld views need to be described in a single device tree. 34*c66ec88fSEmmanuel Vadot 35*c66ec88fSEmmanuel VadotValid Secure world properties 36*c66ec88fSEmmanuel Vadot----------------------------- 37*c66ec88fSEmmanuel Vadot 38*c66ec88fSEmmanuel Vadot- secure-status : specifies whether the device is present and usable 39*c66ec88fSEmmanuel Vadot in the secure world. The combination of this with "status" allows 40*c66ec88fSEmmanuel Vadot the various possible combinations of device visibility to be 41*c66ec88fSEmmanuel Vadot specified. If "secure-status" is not specified it defaults to the 42*c66ec88fSEmmanuel Vadot same value as "status"; if "status" is not specified either then 43*c66ec88fSEmmanuel Vadot both default to "okay". This means the following combinations are 44*c66ec88fSEmmanuel Vadot possible: 45*c66ec88fSEmmanuel Vadot 46*c66ec88fSEmmanuel Vadot /* Neither specified: default to visible in both S and NS */ 47*c66ec88fSEmmanuel Vadot secure-status = "okay"; /* visible in both */ 48*c66ec88fSEmmanuel Vadot status = "okay"; /* visible in both */ 49*c66ec88fSEmmanuel Vadot status = "okay"; secure-status = "okay"; /* visible in both */ 50*c66ec88fSEmmanuel Vadot secure-status = "disabled"; /* NS-only */ 51*c66ec88fSEmmanuel Vadot status = "okay"; secure-status = "disabled"; /* NS-only */ 52*c66ec88fSEmmanuel Vadot status = "disabled"; secure-status = "okay"; /* S-only */ 53*c66ec88fSEmmanuel Vadot status = "disabled"; /* disabled in both */ 54*c66ec88fSEmmanuel Vadot status = "disabled"; secure-status = "disabled"; /* disabled in both */ 55*c66ec88fSEmmanuel Vadot 56*c66ec88fSEmmanuel VadotThe secure-chosen node 57*c66ec88fSEmmanuel Vadot---------------------- 58*c66ec88fSEmmanuel Vadot 59*c66ec88fSEmmanuel VadotSimilar to the /chosen node which serves as a place for passing data 60*c66ec88fSEmmanuel Vadotbetween firmware and the operating system, the /secure-chosen node may 61*c66ec88fSEmmanuel Vadotbe used to pass data to the Secure OS. Only the properties defined 62*c66ec88fSEmmanuel Vadotbelow may appear in the /secure-chosen node. 63*c66ec88fSEmmanuel Vadot 64*c66ec88fSEmmanuel Vadot- stdout-path : specifies the device to be used by the Secure OS for 65*c66ec88fSEmmanuel Vadot its console output. The syntax is the same as for /chosen/stdout-path. 66*c66ec88fSEmmanuel Vadot If the /secure-chosen node exists but the stdout-path property is not 67*c66ec88fSEmmanuel Vadot present, the Secure OS should not perform any console output. If 68*c66ec88fSEmmanuel Vadot /secure-chosen does not exist, the Secure OS should use the value of 69*c66ec88fSEmmanuel Vadot /chosen/stdout-path instead (that is, use the same device as the 70*c66ec88fSEmmanuel Vadot Normal world OS). 71