Bryan Brattlof | 16a30b3 | 2022-12-19 14:29:50 -0600 | [diff] [blame^] | 1 | .. SPDX-License-Identifier: GPL-2.0+ OR BSD-3-Clause |
| 2 | .. sectionauthor:: Bryan Brattlof <bb@ti.com> |
| 3 | |
| 4 | K3 Generation |
| 5 | ============= |
| 6 | |
| 7 | Summary |
| 8 | ------- |
| 9 | |
| 10 | Texas Instrument's K3 family of SoCs utilize a heterogeneous multicore |
| 11 | and highly integrated device architecture targeted to maximize |
| 12 | performance and power efficiency for a wide range of industrial, |
| 13 | automotive and other broad market segments. |
| 14 | |
| 15 | Typically the processing cores and the peripherals for these devices are |
| 16 | partitioned into three functional domains to provide ultra-low power |
| 17 | modes as well as accommodating application and industrial safety systems |
| 18 | on the same SoC. These functional domains are typically called the: |
| 19 | |
| 20 | * Wakeup (WKUP) domain |
| 21 | * Micro-controller (MCU) domain |
| 22 | * Main domain |
| 23 | |
| 24 | For a more detailed view of what peripherals are attached to each |
| 25 | domain, consult the device specific documentation. |
| 26 | |
| 27 | K3 Based SoCs |
| 28 | ------------- |
| 29 | |
| 30 | .. toctree:: |
| 31 | :maxdepth: 1 |
| 32 | |
| 33 | j721e_evm |
| 34 | am62x_sk |
| 35 | |
| 36 | Boot Flow Overview |
| 37 | ------------------ |
| 38 | |
| 39 | For all K3 SoCs the first core started will be inside the Security |
| 40 | Management Subsystem (SMS) which will secure the device and start a core |
| 41 | in the wakeup domain to run the ROM code. ROM will then initialize the |
| 42 | boot media needed to load the binaries packaged inside `tiboot3.bin`, |
| 43 | including a 32bit U-Boot SPL, (called the wakup SPL) that ROM will jump |
| 44 | to after it has finished loading everything into internal SRAM. |
| 45 | |
| 46 | .. code-block:: text |
| 47 | |
| 48 | | WKUP Domain |
| 49 | ROM -> WKUP SPL -> |
| 50 | |
| 51 | The wakeup SPL, running on a wakeup domain core, will initialize DDR and |
| 52 | any peripherals needed load the larger binaries inside the `tispl.bin` |
| 53 | into DDR. Once loaded the wakeup SPL will start one of the 'big' |
| 54 | application cores inside the main domain to initialize the main domain, |
| 55 | starting with ARM Trusted Firmware (ATF), before moving on to start |
| 56 | OPTEE and the main domain's U-Boot SPL. |
| 57 | |
| 58 | .. code-block:: text |
| 59 | |
| 60 | | WKUP Domain | Main Domain -> |
| 61 | ROM -> WKUP SPL -> ATF -> OPTEE -> Main SPL |
| 62 | |
| 63 | The main domain's SPL, running on a 64bit application core, has |
| 64 | virtually unlimited space (billions of bytes now that DDR is working) to |
| 65 | initialize even more peripherals needed to load in the `u-boot.img` |
| 66 | which loads more firmware into the micro-controller & wakeup domains and |
| 67 | finally prepare the main domain to run Linux. |
| 68 | |
| 69 | .. code-block:: text |
| 70 | |
| 71 | | WKUP Domain | Main Domain -> |
| 72 | ROM -> WKUP SPL -> ATF -> OPTEE -> Main SPL -> UBoot -> Linux |
| 73 | |
| 74 | This is the typical boot flow for all K3 based SoCs, however this flow |
| 75 | offers quite a lot in the terms of flexibility, especially on High |
| 76 | Security (HS) SoCs. |
| 77 | |
| 78 | Boot Flow Variations |
| 79 | ^^^^^^^^^^^^^^^^^^^^ |
| 80 | |
| 81 | All K3 SoCs will generally use the above boot flow with two main |
| 82 | differences depending on the capabilities of the boot ROM and the number |
| 83 | of cores inside the device. These differences split the bootflow into |
| 84 | essentially 4 unique but very similar flows: |
| 85 | |
| 86 | * Split binary with a combined firmware: (eg: AM65) |
| 87 | * Combined binary with a combined firmware: (eg: AM64) |
| 88 | * Split binary with a split firmware: (eg: J721E) |
| 89 | * Combined binary with a split firmware: (eg: AM62) |
| 90 | |
| 91 | For devices that utilize the split binary approach, ROM is not capable |
| 92 | of loading the firmware into the SoC requiring the wakeup domain's |
| 93 | U-Boot SPL to load the firmware. |
| 94 | |
| 95 | Devices with a split firmware will have two firmwares loaded into the |
| 96 | device at different times during the bootup process. TI's Foundational |
| 97 | Security (TIFS), needed to operate the Security Management Subsystem, |
| 98 | will either be loaded by ROM or the WKUP U-Boot SPL, then once the |
| 99 | wakeup U-Boot SPL has completed, the second Device Management (DM) |
| 100 | firmware can be loaded on the now free core in the wakeup domain. |
| 101 | |
| 102 | For more information on the bootup process of your SoC, consult the |
| 103 | device specific boot flow documentation. |
| 104 | |
| 105 | Software Sources |
| 106 | ---------------- |
| 107 | |
| 108 | All scripts and code needed to build the `tiboot3.bin`, `tispl.bin` and |
| 109 | `u-boot.img` for all K3 SoCs can be located at the following places |
| 110 | online |
| 111 | |
| 112 | * **Das U-Boot** |
| 113 | |
| 114 | | **source:** https://source.denx.de/u-boot/u-boot.git |
| 115 | | **branch:** master |
| 116 | |
| 117 | * **K3 Image Gen** |
| 118 | |
| 119 | | **source:** https://git.ti.com/git/k3-image-gen/k3-image-gen.git |
| 120 | | **branch:** master |
| 121 | |
| 122 | * **ARM Trusted Firmware (ATF)** |
| 123 | |
| 124 | | **source:** https://github.com/ARM-software/arm-trusted-firmware.git |
| 125 | | **branch:** master |
| 126 | |
| 127 | * **Open Portable Trusted Execution Environment (OPTEE)** |
| 128 | |
| 129 | | **source:** https://github.com/OP-TEE/optee_os.git |
| 130 | | **branch:** master |
| 131 | |
| 132 | * **TI Firmware (TIFS, DM, DSMC)** |
| 133 | |
| 134 | | **source:** https://git.ti.com/git/processor-firmware/ti-linux-firmware.git |
| 135 | | **branch:** ti-linux-firmware |
| 136 | |
| 137 | * **TI's Security Development Tools** |
| 138 | |
| 139 | | **source:** https://git.ti.com/git/security-development-tools/core-secdev-k3.git |
| 140 | | **branch:** master |
| 141 | |
| 142 | Build Procedure |
| 143 | --------------- |
| 144 | |
| 145 | Depending on the specifics of your device, you will need three or more |
| 146 | binaries to boot your SoC. |
| 147 | |
| 148 | * `tiboot3.bin` (bootloader for the wakeup domain) |
| 149 | * `tispl.bin` (bootloader for the main domain) |
| 150 | * `u-boot.img` |
| 151 | |
| 152 | During the bootup process, both the 32bit wakeup domain and the 64bit |
| 153 | main domains will be involved. This means everything inside the |
| 154 | `tiboot3.bin` running in the wakeup domain will need to be compiled for |
| 155 | 32bit cores and most binaries in the `tispl.bin` will need to be |
| 156 | compiled for 64bit main domain CPU cores. |
| 157 | |
| 158 | All of that to say you will need both a 32bit and 64bit cross compiler |
| 159 | (assuming you're using an x86 desktop) |
| 160 | |
| 161 | .. code-block:: bash |
| 162 | |
| 163 | export CC32=arm-linux-gnueabihf- |
| 164 | export CC64=aarch64-linux-gnu- |
| 165 | |
| 166 | Building tiboot3.bin |
| 167 | ^^^^^^^^^^^^^^^^^^^^^ |
| 168 | |
| 169 | 1. To generate the U-Boot SPL for the wakeup domain, use the following |
| 170 | commands, substituting :code:`{SOC}` for the name of your device (eg: |
| 171 | am62x) |
| 172 | |
| 173 | .. code-block:: bash |
| 174 | |
| 175 | # inside u-boot source |
| 176 | make ARCH=arm O=build/wkup CROSS_COMPILE=$CC32 {SOC}_evm_r5_defconfig |
| 177 | make ARCH=arm O=build/wkup CROSS_COMPILE=$CC32 |
| 178 | |
| 179 | 2. Next we will use the K3 Image Gen scripts to package the various |
| 180 | firmware and the wakeup UBoot SPL into the final `tiboot3.bin` |
| 181 | binary. (or the `sysfw.itb` if your device uses the split binary |
| 182 | flow) |
| 183 | |
| 184 | .. code-block:: bash |
| 185 | |
| 186 | # inside k3-image-gen source |
| 187 | make CROSS_COMPILE=$CC32 SOC={SOC} SOC_TYPE={hs,gp} \ |
| 188 | TI_SECURE_DEV_PKG=<path/to/securit-development-tools> \ |
| 189 | SYSFW_PATH=<path/to/ti-sysfw/ti-fs-firmware-{SOC}-{hs|gp}.bin> \ |
| 190 | SYSFW_HS_INNER_CERT_PATH=<path/to/ti-sysfw/ti-fs-firmware-{SOC}-hs-cert.bin |
| 191 | |
| 192 | For devices that use the *combined binary flow*, you will also need to |
| 193 | supply the location of the SPL we created in step 1 above, so it can be |
| 194 | packaged into the final `tiboot3.bin`. |
| 195 | |
| 196 | .. code-block:: bash |
| 197 | |
| 198 | SBL=<path/to/wakeup/u-boot-spl.bin> |
| 199 | |
| 200 | At this point you should have all the needed binaries to boot the wakeup |
| 201 | domain of your K3 SoC. |
| 202 | |
| 203 | **Combined Binary Boot Flow** (eg: am62x, am64x, ... ) |
| 204 | |
| 205 | `k3-image-gen/tiboot3-{SOC}-{hs,gp}-evm.bin` |
| 206 | |
| 207 | **Split Binary Boot Flow** (eg: j721e, am65x) |
| 208 | |
| 209 | | `u-boot/build/wkup/tiboot3.bin` |
| 210 | | `k3-image-gen/sysfw-{SOC}-evm.bin` |
| 211 | |
| 212 | .. note :: |
| 213 | |
| 214 | It's important to rename the generated `tiboot3.bin` and `sysfw.itb` |
| 215 | to match exactly `tiboot3.bin` and `sysfw.itb` as ROM and the wakeup |
| 216 | UBoot SPL will only look for and load the files with these names. |
| 217 | |
| 218 | Building tispl.bin |
| 219 | ^^^^^^^^^^^^^^^^^^^ |
| 220 | |
| 221 | The `tispl.bin` is a standard fitImage combining the firmware need for |
| 222 | the main domain to function properly as well as Device Management (DM) |
| 223 | firmware if your device using a split firmware. |
| 224 | |
| 225 | 3. We will first need ATF, as it's the first thing to run on the 'big' |
| 226 | application cores on the main domain. |
| 227 | |
| 228 | .. code-block:: bash |
| 229 | |
| 230 | # inside arm-trusted-firmware source |
| 231 | make CROSS_COMPILE=$CC64 ARCH=aarch64 PLAT=k3 \ |
| 232 | TARGET_BOARD={lite|generic} \ |
| 233 | SPD=opteed \ |
| 234 | |
| 235 | Typically all `j7*` devices will use `TARGET_BOARD=generic` while all |
| 236 | Sitara (`am6*`) devices use the `lite` option. |
| 237 | |
| 238 | 4. The Open Portable Trusted Execution Environment (OPTEE) is designed |
| 239 | to run as a companion to a non-secure Linux kernel for Cortex-A cores |
| 240 | using the TrustZone technology built into the core. |
| 241 | |
| 242 | .. code-block:: bash |
| 243 | |
| 244 | # inside optee_os source |
| 245 | make CROSS_COMPILE=$CC32 CROSS_COMPILE64=$CC64 \ |
| 246 | PLATFORM=k3 CFG_ARM64_core=y |
| 247 | |
| 248 | 5. Finally, after ATF has initialized the main domain and OPTEE has |
| 249 | finished, we can jump back into U-Boot again, this time running on a |
| 250 | 64bit core in the main domain. |
| 251 | |
| 252 | .. code-block:: bash |
| 253 | |
| 254 | # inside u-boot source |
| 255 | make ARCH=arm O=build/main CROSS_COMPILE=$CC64 {SOC}_evm_a{53,72}_defconfig |
| 256 | make ARCH=arm O=build/main CROSS_COMPILE=$CC64 \ |
| 257 | ATF=<path/to/atf/bl31.bin \ |
| 258 | TEE=<path/to/optee/tee-pager_v2.bin |
| 259 | |
| 260 | If your device uses a split firmware, you will also need to supply the |
| 261 | path to the Device Management (DM) Firmware to be included in the final |
| 262 | `tispl.bin` binary |
| 263 | |
| 264 | .. code-block:: bash |
| 265 | |
| 266 | DM=<path/to/ti-linux-firmware/ti-dm/ipc_echo_testb_mcu1_0_release_strip.xer5f> |
| 267 | |
| 268 | At this point you should have every binary needed initialize both the |
| 269 | wakeup and main domain and to boot to the U-Boot prompt |
| 270 | |
| 271 | **Main Domain Bootloader** |
| 272 | |
| 273 | | `u-boot/build/main/tispl.bin` |
| 274 | | `u-boot/build/main/u-boot.img` |