71 lines · plain
1* ARM Secure world bindings2 3ARM CPUs with TrustZone support have two distinct address spaces,4"Normal" and "Secure". Most devicetree consumers (including the Linux5kernel) are not TrustZone aware and run entirely in either the Normal6world or the Secure world. However some devicetree consumers are7TrustZone aware and need to be able to determine whether devices are8visible only in the Secure address space, only in the Normal address9space, or visible in both. (One example of that situation would be a10virtual machine which boots Secure firmware and wants to tell the11firmware about the layout of the machine via devicetree.)12 13The general principle of the naming scheme for Secure world bindings14is that any property that needs a different value in the Secure world15can be supported by prefixing the property name with "secure-". So for16instance "secure-foo" would override "foo". For property names with17a vendor prefix, the Secure variant of "vendor,foo" would be18"vendor,secure-foo". If there is no "secure-" property then the Secure19world value is the same as specified for the Normal world by the20non-prefixed property. However, only the properties listed below may21validly have "secure-" versions; this list will be enlarged on a22case-by-case basis.23 24Defining the bindings in this way means that a device tree which has25been annotated to indicate the presence of Secure-only devices can26still be processed unmodified by existing Non-secure software (and in27particular by the kernel).28 29Note that it is still valid for bindings intended for purely Secure30world consumers (like kernels that run entirely in Secure) to simply31describe the view of Secure world using the standard bindings. These32secure- bindings only need to be used where both the Secure and Normal33world views need to be described in a single device tree.34 35Valid Secure world properties36-----------------------------37 38- secure-status : specifies whether the device is present and usable39 in the secure world. The combination of this with "status" allows40 the various possible combinations of device visibility to be41 specified. If "secure-status" is not specified it defaults to the42 same value as "status"; if "status" is not specified either then43 both default to "okay". This means the following combinations are44 possible:45 46 /* Neither specified: default to visible in both S and NS */47 secure-status = "okay"; /* visible in both */48 status = "okay"; /* visible in both */49 status = "okay"; secure-status = "okay"; /* visible in both */50 secure-status = "disabled"; /* NS-only */51 status = "okay"; secure-status = "disabled"; /* NS-only */52 status = "disabled"; secure-status = "okay"; /* S-only */53 status = "disabled"; /* disabled in both */54 status = "disabled"; secure-status = "disabled"; /* disabled in both */55 56The secure-chosen node57----------------------58 59Similar to the /chosen node which serves as a place for passing data60between firmware and the operating system, the /secure-chosen node may61be used to pass data to the Secure OS. Only the properties defined62below may appear in the /secure-chosen node.63 64- stdout-path : specifies the device to be used by the Secure OS for65 its console output. The syntax is the same as for /chosen/stdout-path.66 If the /secure-chosen node exists but the stdout-path property is not67 present, the Secure OS should not perform any console output. If68 /secure-chosen does not exist, the Secure OS should use the value of69 /chosen/stdout-path instead (that is, use the same device as the70 Normal world OS).71