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