mirror of https://gitee.com/openkylin/linux.git
71 lines
3.6 KiB
Plaintext
71 lines
3.6 KiB
Plaintext
* ARM Secure world bindings
|
|
|
|
ARM CPUs with TrustZone support have two distinct address spaces,
|
|
"Normal" and "Secure". Most devicetree consumers (including the Linux
|
|
kernel) are not TrustZone aware and run entirely in either the Normal
|
|
world or the Secure world. However some devicetree consumers are
|
|
TrustZone aware and need to be able to determine whether devices are
|
|
visible only in the Secure address space, only in the Normal address
|
|
space, or visible in both. (One example of that situation would be a
|
|
virtual machine which boots Secure firmware and wants to tell the
|
|
firmware about the layout of the machine via devicetree.)
|
|
|
|
The general principle of the naming scheme for Secure world bindings
|
|
is that any property that needs a different value in the Secure world
|
|
can be supported by prefixing the property name with "secure-". So for
|
|
instance "secure-foo" would override "foo". For property names with
|
|
a vendor prefix, the Secure variant of "vendor,foo" would be
|
|
"vendor,secure-foo". If there is no "secure-" property then the Secure
|
|
world value is the same as specified for the Normal world by the
|
|
non-prefixed property. However, only the properties listed below may
|
|
validly have "secure-" versions; this list will be enlarged on a
|
|
case-by-case basis.
|
|
|
|
Defining the bindings in this way means that a device tree which has
|
|
been annotated to indicate the presence of Secure-only devices can
|
|
still be processed unmodified by existing Non-secure software (and in
|
|
particular by the kernel).
|
|
|
|
Note that it is still valid for bindings intended for purely Secure
|
|
world consumers (like kernels that run entirely in Secure) to simply
|
|
describe the view of Secure world using the standard bindings. These
|
|
secure- bindings only need to be used where both the Secure and Normal
|
|
world views need to be described in a single device tree.
|
|
|
|
Valid Secure world properties
|
|
-----------------------------
|
|
|
|
- secure-status : specifies whether the device is present and usable
|
|
in the secure world. The combination of this with "status" allows
|
|
the various possible combinations of device visibility to be
|
|
specified. If "secure-status" is not specified it defaults to the
|
|
same value as "status"; if "status" is not specified either then
|
|
both default to "okay". This means the following combinations are
|
|
possible:
|
|
|
|
/* Neither specified: default to visible in both S and NS */
|
|
secure-status = "okay"; /* visible in both */
|
|
status = "okay"; /* visible in both */
|
|
status = "okay"; secure-status = "okay"; /* visible in both */
|
|
secure-status = "disabled"; /* NS-only */
|
|
status = "okay"; secure-status = "disabled"; /* NS-only */
|
|
status = "disabled"; secure-status = "okay"; /* S-only */
|
|
status = "disabled"; /* disabled in both */
|
|
status = "disabled"; secure-status = "disabled"; /* disabled in both */
|
|
|
|
The secure-chosen node
|
|
----------------------
|
|
|
|
Similar to the /chosen node which serves as a place for passing data
|
|
between firmware and the operating system, the /secure-chosen node may
|
|
be used to pass data to the Secure OS. Only the properties defined
|
|
below may appear in the /secure-chosen node.
|
|
|
|
- stdout-path : specifies the device to be used by the Secure OS for
|
|
its console output. The syntax is the same as for /chosen/stdout-path.
|
|
If the /secure-chosen node exists but the stdout-path property is not
|
|
present, the Secure OS should not perform any console output. If
|
|
/secure-chosen does not exist, the Secure OS should use the value of
|
|
/chosen/stdout-path instead (that is, use the same device as the
|
|
Normal world OS).
|