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