Joakim Bech | 8e5c5b3 | 2018-10-25 08:18:32 +0200 | [diff] [blame] | 1 | .. _device_tree: |
| 2 | |
| 3 | ########### |
| 4 | Device Tree |
| 5 | ########### |
| 6 | OP-TEE core can use the device tree format to inject platform configuration |
| 7 | information during platform initialization and possibly some run time contexts. |
| 8 | |
| 9 | Device Tree technology allows to describe platforms from ASCII source files |
| 10 | so-called DTS files. These can be used to generate a platform description binary |
| 11 | image, so-called DTB, embedded in the platform boot media for applying expected |
| 12 | configuration settings during the platform initializations. |
| 13 | |
| 14 | This scheme relaxes design constraints on the OP-TEE core implementation as most |
| 15 | of the platform specific hardware can be tuned without modifying C source files |
| 16 | or adding configuration directives in the build environments. |
| 17 | |
| 18 | Secure and Non-Secure Device Trees |
| 19 | ********************************** |
| 20 | There can be several device trees embedded in the target system and some can be |
| 21 | shared across the boot stages. |
| 22 | |
| 23 | - Boot loader stages may load a device tree structure in memory for all boot |
| 24 | stage to get platform configuration from. If such device tree data are to |
| 25 | be accessed by the non-secure world, they shall be located in non-secure |
| 26 | memory. |
| 27 | |
| 28 | - Boot loader stages may load a device tree structure in secure memory for |
| 29 | the benefit of the secure world only. Such device tree blob shall be |
| 30 | located in secure memory. |
| 31 | |
| 32 | - OP-TEE core can also embedded a device tree structure to describe the |
| 33 | platform. |
| 34 | |
| 35 | - Non-secure world can embed a device tree structure and/or rely on a device |
| 36 | tree structure loaded by the secure world, being an early boot stage |
| 37 | and/or OP-TEE core. |
| 38 | |
| 39 | Obviously the non-secure world will not be able to access a device tree image |
| 40 | located on a secure memory which non-secure world as no access to. |
| 41 | |
| 42 | Early boot device tree argument |
| 43 | ******************************* |
| 44 | The bootloader provides arguments to the OP-TEE core when it boots it. Among |
| 45 | those, the physical memory base address of a device tree image accessible to |
| 46 | OP-TEE core. |
| 47 | |
| 48 | When OP-TEE core is built with ``CFG_DT=y`` this device tree is accessed by |
| 49 | OP-TEE core to get some information: console configuration, main memory size. |
| 50 | |
| 51 | OP-TEE will also try to add the description of the OP-TEE resources for the |
| 52 | non-secure world to properly communicate with OP-TEE. This assumes the image is |
| 53 | located in non-secure memory. |
| 54 | |
| 55 | Modifications made by OP-TEE core on the non-secure device tree image provided |
| 56 | by early boot and passed to non-secure world are the following: |
| 57 | |
| 58 | - Add an OP-TEE node if none found with the related invocation parameters. |
| 59 | |
| 60 | - Add a reserved memory node for the few memory areas that shall be reserved |
| 61 | to the secure world and non accessed by the non-secure world. |
| 62 | |
| 63 | - Add a PSCI description node if none found. |
| 64 | |
| 65 | Early boot DTB located in non-secure memory can be accessed by OP-TEE core only |
| 66 | during its initialization, before non-secure world boots. |
| 67 | |
| 68 | Embedded Secure Device Tree |
| 69 | *************************** |
| 70 | When OP-TEE core is built with configuration directive ``CFG_EMBED_DTB=y`` |
| 71 | directive ``CFG_EMBED_DTB_SOURCE_FILE`` shall provide the relative path of the |
| 72 | DTS file inside directory ``core/arch/$(ARCH)/dts`` from which a DTB is |
| 73 | generated and embedded in a read-only section of OP-TEE core. |
| 74 | |
| 75 | In this case the device tree address passed to the OP-TEE entry point by the |
| 76 | bootloader is ignored, only the embedded device tree is accessible. |