blob: b49a60caf133979844be6bcb471743ba87a9bf38 [file] [log] [blame]
Bryan Brattlof16a30b32022-12-19 14:29:50 -06001.. SPDX-License-Identifier: GPL-2.0+ OR BSD-3-Clause
2.. sectionauthor:: Bryan Brattlof <bb@ti.com>
3
4K3 Generation
5=============
6
7Summary
8-------
9
10Texas Instrument's K3 family of SoCs utilize a heterogeneous multicore
11and highly integrated device architecture targeted to maximize
12performance and power efficiency for a wide range of industrial,
13automotive and other broad market segments.
14
15Typically the processing cores and the peripherals for these devices are
16partitioned into three functional domains to provide ultra-low power
17modes as well as accommodating application and industrial safety systems
18on the same SoC. These functional domains are typically called the:
19
20* Wakeup (WKUP) domain
21* Micro-controller (MCU) domain
22* Main domain
23
24For a more detailed view of what peripherals are attached to each
25domain, consult the device specific documentation.
26
27K3 Based SoCs
28-------------
29
30.. toctree::
31 :maxdepth: 1
32
33 j721e_evm
34 am62x_sk
35
36Boot Flow Overview
37------------------
38
39For all K3 SoCs the first core started will be inside the Security
40Management Subsystem (SMS) which will secure the device and start a core
41in the wakeup domain to run the ROM code. ROM will then initialize the
42boot media needed to load the binaries packaged inside `tiboot3.bin`,
43including a 32bit U-Boot SPL, (called the wakup SPL) that ROM will jump
44to after it has finished loading everything into internal SRAM.
45
46.. code-block:: text
47
48 | WKUP Domain
49 ROM -> WKUP SPL ->
50
51The wakeup SPL, running on a wakeup domain core, will initialize DDR and
52any peripherals needed load the larger binaries inside the `tispl.bin`
53into DDR. Once loaded the wakeup SPL will start one of the 'big'
54application cores inside the main domain to initialize the main domain,
55starting with ARM Trusted Firmware (ATF), before moving on to start
56OPTEE 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
63The main domain's SPL, running on a 64bit application core, has
64virtually unlimited space (billions of bytes now that DDR is working) to
65initialize even more peripherals needed to load in the `u-boot.img`
66which loads more firmware into the micro-controller & wakeup domains and
67finally 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
74This is the typical boot flow for all K3 based SoCs, however this flow
75offers quite a lot in the terms of flexibility, especially on High
76Security (HS) SoCs.
77
78Boot Flow Variations
79^^^^^^^^^^^^^^^^^^^^
80
81All K3 SoCs will generally use the above boot flow with two main
82differences depending on the capabilities of the boot ROM and the number
83of cores inside the device. These differences split the bootflow into
84essentially 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
91For devices that utilize the split binary approach, ROM is not capable
92of loading the firmware into the SoC requiring the wakeup domain's
93U-Boot SPL to load the firmware.
94
95Devices with a split firmware will have two firmwares loaded into the
96device at different times during the bootup process. TI's Foundational
97Security (TIFS), needed to operate the Security Management Subsystem,
98will either be loaded by ROM or the WKUP U-Boot SPL, then once the
99wakeup U-Boot SPL has completed, the second Device Management (DM)
100firmware can be loaded on the now free core in the wakeup domain.
101
102For more information on the bootup process of your SoC, consult the
103device specific boot flow documentation.
104
105Software Sources
106----------------
107
108All 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
110online
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
142Build Procedure
143---------------
144
145Depending on the specifics of your device, you will need three or more
146binaries 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
152During the bootup process, both the 32bit wakeup domain and the 64bit
153main domains will be involved. This means everything inside the
154`tiboot3.bin` running in the wakeup domain will need to be compiled for
15532bit cores and most binaries in the `tispl.bin` will need to be
156compiled for 64bit main domain CPU cores.
157
158All 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
166Building tiboot3.bin
167^^^^^^^^^^^^^^^^^^^^^
168
1691. 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
1792. 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
192For devices that use the *combined binary flow*, you will also need to
193supply the location of the SPL we created in step 1 above, so it can be
194packaged into the final `tiboot3.bin`.
195
196.. code-block:: bash
197
198 SBL=<path/to/wakeup/u-boot-spl.bin>
199
200At this point you should have all the needed binaries to boot the wakeup
201domain 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
218Building tispl.bin
219^^^^^^^^^^^^^^^^^^^
220
221The `tispl.bin` is a standard fitImage combining the firmware need for
222the main domain to function properly as well as Device Management (DM)
223firmware if your device using a split firmware.
224
2253. 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
235Typically all `j7*` devices will use `TARGET_BOARD=generic` while all
236Sitara (`am6*`) devices use the `lite` option.
237
2384. 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
2485. 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
260If your device uses a split firmware, you will also need to supply the
261path 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
268At this point you should have every binary needed initialize both the
269wakeup 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`