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