blob: 88821a15e4c6400feb31eef06e8d8b1afdf9aacf [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
Jai Luthrae526653e2023-11-13 08:51:49 -060033 am62ax_sk
Bryan Brattlof6d138132022-12-19 14:29:50 -060034 am62x_sk
Nishanth Menon1f2b6f92023-11-04 03:01:36 -050035 ../beagle/am62x_beagleplay
Wadim Egorov12722a42023-12-20 10:18:11 +010036 ../phytec/phycore-am62x
Marcel Ziswiler315deb32023-08-04 12:08:08 +020037 ../toradex/verdin-am62
Bryan Brattlofcf2e2b12024-03-12 15:20:30 -050038 am62px_sk
Roger Quadroscd87b1e2023-08-05 11:14:39 +030039 am64x_evm
Neha Malcom Francis507be122023-07-22 00:14:43 +053040 am65x_evm
Nishanth Menone83fe672023-07-27 13:59:01 -050041 j7200_evm
Nishanth Menon756b8782023-11-04 03:11:03 -050042 ../beagle/j721e_beagleboneai64
Nishanth Menone83fe672023-07-27 13:59:01 -050043 j721e_evm
Manorit Chawdhry670a22b2023-10-06 10:16:00 +053044 j721s2_evm
Apurva Nandan2b1c9ff2024-02-24 01:51:53 +053045 j784s4_evm
Bryan Brattlof6d138132022-12-19 14:29:50 -060046
47Boot Flow Overview
48------------------
49
50For all K3 SoCs the first core started will be inside the Security
51Management Subsystem (SMS) which will secure the device and start a core
52in the wakeup domain to run the ROM code. ROM will then initialize the
53boot media needed to load the binaries packaged inside `tiboot3.bin`,
54including a 32bit U-Boot SPL, (called the wakup SPL) that ROM will jump
55to after it has finished loading everything into internal SRAM.
56
Nishanth Menon7bdb2d52023-07-27 13:59:02 -050057.. image:: img/boot_flow_01.svg
Heinrich Schuchardtd0894b22023-08-22 11:40:55 -050058 :alt: Boot flow up to wakeup domain SPL
Bryan Brattlof6d138132022-12-19 14:29:50 -060059
60The wakeup SPL, running on a wakeup domain core, will initialize DDR and
61any peripherals needed load the larger binaries inside the `tispl.bin`
62into DDR. Once loaded the wakeup SPL will start one of the 'big'
63application cores inside the main domain to initialize the main domain,
Neha Malcom Francis507be122023-07-22 00:14:43 +053064starting with Trusted Firmware-A (TF-A), before moving on to start
65OP-TEE and the main domain's U-Boot SPL.
Bryan Brattlof6d138132022-12-19 14:29:50 -060066
Nishanth Menon7bdb2d52023-07-27 13:59:02 -050067.. image:: img/boot_flow_02.svg
Heinrich Schuchardtd0894b22023-08-22 11:40:55 -050068 :alt: Boot flow up to main domain SPL
Bryan Brattlof6d138132022-12-19 14:29:50 -060069
70The main domain's SPL, running on a 64bit application core, has
71virtually unlimited space (billions of bytes now that DDR is working) to
72initialize even more peripherals needed to load in the `u-boot.img`
73which loads more firmware into the micro-controller & wakeup domains and
74finally prepare the main domain to run Linux.
75
Nishanth Menon7bdb2d52023-07-27 13:59:02 -050076.. image:: img/boot_flow_03.svg
Heinrich Schuchardtd0894b22023-08-22 11:40:55 -050077 :alt: Complete boot flow up to Linux
Bryan Brattlof6d138132022-12-19 14:29:50 -060078
79This is the typical boot flow for all K3 based SoCs, however this flow
80offers quite a lot in the terms of flexibility, especially on High
81Security (HS) SoCs.
82
83Boot Flow Variations
84^^^^^^^^^^^^^^^^^^^^
85
86All K3 SoCs will generally use the above boot flow with two main
87differences depending on the capabilities of the boot ROM and the number
88of cores inside the device. These differences split the bootflow into
89essentially 4 unique but very similar flows:
90
91* Split binary with a combined firmware: (eg: AM65)
92* Combined binary with a combined firmware: (eg: AM64)
93* Split binary with a split firmware: (eg: J721E)
94* Combined binary with a split firmware: (eg: AM62)
95
96For devices that utilize the split binary approach, ROM is not capable
97of loading the firmware into the SoC requiring the wakeup domain's
98U-Boot SPL to load the firmware.
99
100Devices with a split firmware will have two firmwares loaded into the
101device at different times during the bootup process. TI's Foundational
102Security (TIFS), needed to operate the Security Management Subsystem,
103will either be loaded by ROM or the WKUP U-Boot SPL, then once the
104wakeup U-Boot SPL has completed, the second Device Management (DM)
105firmware can be loaded on the now free core in the wakeup domain.
106
107For more information on the bootup process of your SoC, consult the
108device specific boot flow documentation.
109
Manorit Chawdhry98346472023-12-29 16:16:33 +0530110Secure Boot
111-----------
112
113K3 HS-SE (High Security - Security Enforced) devices enforce an
114authenticated boot flow for secure boot. HS-FS (High Security - Field
115Securable) is the state of a K3 device before it has been eFused with
116customer security keys. In the HS-FS state the authentication still can
117function as in HS-SE but as there are no customer keys to verify the
118signatures against the authentication will pass for certificates signed
119with any key.
120
121Chain of trust
122^^^^^^^^^^^^^^
123
1241) Public ROM loads the tiboot3.bin (R5 SPL, TIFS)
1252) R5 SPL loads tispl.bin (ATF, OP-TEE, DM, SPL)
1263) SPL loads u-boot.img (U-Boot)
1274) U-Boot loads fitImage (Linux and DTBs)
128
129Steps 1-3 are all authenticated by either the Secure ROM or TIFS as the
130authenticating entity and step 4 uses U-boot standard mechanism for
131authenticating.
132
133All the authentication that are done for ROM/TIFS are done through x509
134certificates that are signed.
135
136Firewalls
137^^^^^^^^^
138
1391) Secure ROM comes up and sets up firewalls that are needed by itself
1402) TIFS will setup it's own firewalls to protect core system resources
1413) R5 SPL will remove any firewalls that are leftover from the Secure ROM stage
142 that are no longer required.
1434) Each stage beyond this: such as tispl.bin containing TFA/OPTEE uses OIDs to
144 set up firewalls to protect themselves (enforced by TIFS)
1455) TFA/OP-TEE can configure other firewalls at runtime if required as they
146 are already authenticated and firewalled off from illegal access.
1476) All later stages can setup or remove firewalls that have not been already
148 configured by previous stages, such as those created by TIFS, TFA, and OP-TEE.
149
150Futhur, firewalls have a lockdown bit in hardware that enforces the setting
151(and cannot be over-ridden) until the full system is reset.
152
Bryan Brattlof6d138132022-12-19 14:29:50 -0600153Software Sources
154----------------
155
156All scripts and code needed to build the `tiboot3.bin`, `tispl.bin` and
157`u-boot.img` for all K3 SoCs can be located at the following places
158online
159
Nishanth Menonee91e482023-07-27 13:58:44 -0500160.. k3_rst_include_start_boot_sources
161
Bryan Brattlof6d138132022-12-19 14:29:50 -0600162* **Das U-Boot**
163
164 | **source:** https://source.denx.de/u-boot/u-boot.git
165 | **branch:** master
166
Neha Malcom Francis507be122023-07-22 00:14:43 +0530167* **Trusted Firmware-A (TF-A)**
Bryan Brattlof6d138132022-12-19 14:29:50 -0600168
Neha Malcom Francis507be122023-07-22 00:14:43 +0530169 | **source:** https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/
Bryan Brattlof6d138132022-12-19 14:29:50 -0600170 | **branch:** master
171
Neha Malcom Francis507be122023-07-22 00:14:43 +0530172* **Open Portable Trusted Execution Environment (OP-TEE)**
Bryan Brattlof6d138132022-12-19 14:29:50 -0600173
174 | **source:** https://github.com/OP-TEE/optee_os.git
175 | **branch:** master
176
Nishanth Menone2a47452023-08-22 11:41:07 -0500177* **TI Firmware (TIFS, DM, SYSFW)**
Bryan Brattlof6d138132022-12-19 14:29:50 -0600178
179 | **source:** https://git.ti.com/git/processor-firmware/ti-linux-firmware.git
180 | **branch:** ti-linux-firmware
181
Nishanth Menone2a47452023-08-22 11:41:07 -0500182.. note::
183
184 The TI Firmware required for functionality of the system can be
185 one of the following combination (see platform specific boot diagram for
186 further information as to which component runs on which processor):
187
188 * **TIFS** - TI Foundational Security Firmware - Consists of purely firmware
189 meant to run on the security enclave.
190 * **DM** - Device Management firmware also called TI System Control Interface
191 server (TISCI Server) - This component purely plays the role of managing
192 device resources such as power, clock, interrupts, dma etc. This firmware
193 runs on a dedicated or multi-use microcontroller outside the security
194 enclave.
195
196 OR
197
198 * **SYSFW** - System firmware - consists of both TIFS and DM both running on
199 the security enclave.
200
Nishanth Menonee91e482023-07-27 13:58:44 -0500201.. k3_rst_include_end_boot_sources
202
Bryan Brattlof6d138132022-12-19 14:29:50 -0600203Build Procedure
204---------------
205
Jonathan Humphreys43d44fa2024-06-21 15:17:06 -0500206.. note ::
207
208 Make sure you have installed all necessary host package dependencies
209 before proceeding. See :ref:`build/gcc:Building with GCC`.
210
Bryan Brattlof6d138132022-12-19 14:29:50 -0600211Depending on the specifics of your device, you will need three or more
212binaries to boot your SoC.
213
214* `tiboot3.bin` (bootloader for the wakeup domain)
215* `tispl.bin` (bootloader for the main domain)
216* `u-boot.img`
217
218During the bootup process, both the 32bit wakeup domain and the 64bit
219main domains will be involved. This means everything inside the
220`tiboot3.bin` running in the wakeup domain will need to be compiled for
22132bit cores and most binaries in the `tispl.bin` will need to be
222compiled for 64bit main domain CPU cores.
223
224All of that to say you will need both a 32bit and 64bit cross compiler
225(assuming you're using an x86 desktop)
226
Nishanth Menonb7ee22f2023-07-27 13:58:48 -0500227.. k3_rst_include_start_common_env_vars_desc
228.. list-table:: Generic environment variables
229 :widths: 25 25 50
230 :header-rows: 1
231
232 * - S/w Component
233 - Env Variable
234 - Description
235 * - All Software
236 - CC32
237 - Cross compiler for ARMv7 (ARM 32bit), typically arm-linux-gnueabihf-
238 * - All Software
239 - CC64
240 - Cross compiler for ARMv8 (ARM 64bit), typically aarch64-linux-gnu-
241 * - All Software
242 - LNX_FW_PATH
243 - Path to TI Linux firmware repository
244 * - All Software
245 - TFA_PATH
246 - Path to source of Trusted Firmware-A
247 * - All Software
248 - OPTEE_PATH
249 - Path to source of OP-TEE
250.. k3_rst_include_end_common_env_vars_desc
251
252.. k3_rst_include_start_common_env_vars_defn
Nishanth Menon740c41c2023-11-02 23:40:25 -0500253.. prompt:: bash $
Bryan Brattlof6d138132022-12-19 14:29:50 -0600254
Nishanth Menon55fbcae2023-08-24 10:40:36 -0500255 export CC32=arm-linux-gnueabihf-
256 export CC64=aarch64-linux-gnu-
257 export LNX_FW_PATH=path/to/ti-linux-firmware
258 export TFA_PATH=path/to/trusted-firmware-a
259 export OPTEE_PATH=path/to/optee_os
Nishanth Menonb7ee22f2023-07-27 13:58:48 -0500260.. k3_rst_include_end_common_env_vars_defn
261
262We will also need some common environment variables set up for the various
263other build sources. we shall use the following, in the build descriptions below:
264
265.. k3_rst_include_start_board_env_vars_desc
266.. list-table:: Board specific environment variables
267 :widths: 25 25 50
268 :header-rows: 1
269
270 * - S/w Component
271 - Env Variable
272 - Description
273 * - U-Boot
274 - UBOOT_CFG_CORTEXR
275 - Defconfig for Cortex-R (Boot processor).
276 * - U-Boot
277 - UBOOT_CFG_CORTEXA
278 - Defconfig for Cortex-A (MPU processor).
279 * - Trusted Firmware-A
280 - TFA_BOARD
281 - Platform name used for building TF-A for Cortex-A Processor.
282 * - Trusted Firmware-A
283 - TFA_EXTRA_ARGS
284 - Any extra arguments used for building TF-A.
285 * - OP-TEE
286 - OPTEE_PLATFORM
287 - Platform name used for building OP-TEE for Cortex-A Processor.
288 * - OP-TEE
289 - OPTEE_EXTRA_ARGS
290 - Any extra arguments used for building OP-TEE.
291.. k3_rst_include_end_board_env_vars_desc
Bryan Brattlof6d138132022-12-19 14:29:50 -0600292
293Building tiboot3.bin
Heinrich Schuchardtb72160b2023-10-28 11:59:32 +0200294^^^^^^^^^^^^^^^^^^^^
Bryan Brattlof6d138132022-12-19 14:29:50 -0600295
2961. To generate the U-Boot SPL for the wakeup domain, use the following
297 commands, substituting :code:`{SOC}` for the name of your device (eg:
Neha Malcom Francis507be122023-07-22 00:14:43 +0530298 am62x) to package the various firmware and the wakeup UBoot SPL into
299 the final `tiboot3.bin` binary. (or the `sysfw.itb` if your device
300 uses the split binary flow)
Bryan Brattlof6d138132022-12-19 14:29:50 -0600301
Manorit Chawdhryf64b3bd2023-12-29 16:16:32 +0530302.. _k3_rst_include_start_build_steps_spl_r5:
303
Nishanth Menonb7ee22f2023-07-27 13:58:48 -0500304.. k3_rst_include_start_build_steps_spl_r5
Nishanth Menon740c41c2023-11-02 23:40:25 -0500305.. prompt:: bash $
Bryan Brattlof6d138132022-12-19 14:29:50 -0600306
Nishanth Menon55fbcae2023-08-24 10:40:36 -0500307 # inside u-boot source
308 make $UBOOT_CFG_CORTEXR
309 make CROSS_COMPILE=$CC32 BINMAN_INDIRS=$LNX_FW_PATH
Nishanth Menonb7ee22f2023-07-27 13:58:48 -0500310.. k3_rst_include_end_build_steps_spl_r5
Bryan Brattlof6d138132022-12-19 14:29:50 -0600311
312At this point you should have all the needed binaries to boot the wakeup
313domain of your K3 SoC.
314
315**Combined Binary Boot Flow** (eg: am62x, am64x, ... )
316
Neha Malcom Francis507be122023-07-22 00:14:43 +0530317 `tiboot3-{SOC}-{gp/hs-fs/hs}.bin`
Bryan Brattlof6d138132022-12-19 14:29:50 -0600318
319**Split Binary Boot Flow** (eg: j721e, am65x)
320
Neha Malcom Francis507be122023-07-22 00:14:43 +0530321 | `tiboot3-{SOC}-{gp/hs-fs/hs}.bin`
322 | `sysfw-{SOC}-{gp/hs-fs/hs}-evm.itb`
Bryan Brattlof6d138132022-12-19 14:29:50 -0600323
324.. note ::
325
326 It's important to rename the generated `tiboot3.bin` and `sysfw.itb`
327 to match exactly `tiboot3.bin` and `sysfw.itb` as ROM and the wakeup
328 UBoot SPL will only look for and load the files with these names.
329
330Building tispl.bin
Heinrich Schuchardtb72160b2023-10-28 11:59:32 +0200331^^^^^^^^^^^^^^^^^^
Bryan Brattlof6d138132022-12-19 14:29:50 -0600332
333The `tispl.bin` is a standard fitImage combining the firmware need for
334the main domain to function properly as well as Device Management (DM)
335firmware if your device using a split firmware.
336
Neha Malcom Francis507be122023-07-22 00:14:43 +05303372. We will first need TF-A, as it's the first thing to run on the 'big'
Bryan Brattlof6d138132022-12-19 14:29:50 -0600338 application cores on the main domain.
339
Nishanth Menonb7ee22f2023-07-27 13:58:48 -0500340.. k3_rst_include_start_build_steps_tfa
Nishanth Menon740c41c2023-11-02 23:40:25 -0500341.. prompt:: bash $
Bryan Brattlof6d138132022-12-19 14:29:50 -0600342
Nishanth Menon55fbcae2023-08-24 10:40:36 -0500343 # inside trusted-firmware-a source
344 make CROSS_COMPILE=$CC64 ARCH=aarch64 PLAT=k3 SPD=opteed $TFA_EXTRA_ARGS \
345 TARGET_BOARD=$TFA_BOARD
Nishanth Menonb7ee22f2023-07-27 13:58:48 -0500346.. k3_rst_include_end_build_steps_tfa
Bryan Brattlof6d138132022-12-19 14:29:50 -0600347
Neha Malcom Francis507be122023-07-22 00:14:43 +0530348Typically all `j7*` devices will use `TARGET_BOARD=generic` or `TARGET_BOARD
Nishanth Menonb7ee22f2023-07-27 13:58:48 -0500349=j784s4` (if it is a J784S4 device), while typical Sitara (`am6*`) devices
Neha Malcom Francis507be122023-07-22 00:14:43 +0530350use the `lite` option.
Bryan Brattlof6d138132022-12-19 14:29:50 -0600351
Neha Malcom Francis507be122023-07-22 00:14:43 +05303523. The Open Portable Trusted Execution Environment (OP-TEE) is designed
Bryan Brattlof6d138132022-12-19 14:29:50 -0600353 to run as a companion to a non-secure Linux kernel for Cortex-A cores
354 using the TrustZone technology built into the core.
355
Nishanth Menonb7ee22f2023-07-27 13:58:48 -0500356.. k3_rst_include_start_build_steps_optee
Nishanth Menon740c41c2023-11-02 23:40:25 -0500357.. prompt:: bash $
Bryan Brattlof6d138132022-12-19 14:29:50 -0600358
Nishanth Menon55fbcae2023-08-24 10:40:36 -0500359 # inside optee_os source
360 make CROSS_COMPILE=$CC32 CROSS_COMPILE64=$CC64 CFG_ARM64_core=y $OPTEE_EXTRA_ARGS \
361 PLATFORM=$OPTEE_PLATFORM
Nishanth Menonb7ee22f2023-07-27 13:58:48 -0500362.. k3_rst_include_end_build_steps_optee
Bryan Brattlof6d138132022-12-19 14:29:50 -0600363
Neha Malcom Francis507be122023-07-22 00:14:43 +05303644. Finally, after TF-A has initialized the main domain and OP-TEE has
Bryan Brattlof6d138132022-12-19 14:29:50 -0600365 finished, we can jump back into U-Boot again, this time running on a
366 64bit core in the main domain.
367
Manorit Chawdhryf64b3bd2023-12-29 16:16:32 +0530368.. _k3_rst_include_start_build_steps_uboot:
369
Nishanth Menonb7ee22f2023-07-27 13:58:48 -0500370.. k3_rst_include_start_build_steps_uboot
Nishanth Menon740c41c2023-11-02 23:40:25 -0500371.. prompt:: bash $
Bryan Brattlof6d138132022-12-19 14:29:50 -0600372
Nishanth Menon55fbcae2023-08-24 10:40:36 -0500373 # inside u-boot source
374 make $UBOOT_CFG_CORTEXA
375 make CROSS_COMPILE=$CC64 BINMAN_INDIRS=$LNX_FW_PATH \
Nishanth Menonb7ee22f2023-07-27 13:58:48 -0500376 BL31=$TFA_PATH/build/k3/$TFA_BOARD/release/bl31.bin \
377 TEE=$OPTEE_PATH/out/arm-plat-k3/core/tee-raw.bin
Neha Malcom Francis2b259f02023-12-05 15:12:20 +0530378
379.. note::
380 It is also possible to pick up a custom DM binary by adding TI_DM argument
381 pointing to the file. If not provided, it defaults to picking up the DM
382 binary from BINMAN_INDIRS. This is only applicable to devices that utilize
383 split firmware.
384
Nishanth Menonb7ee22f2023-07-27 13:58:48 -0500385.. k3_rst_include_end_build_steps_uboot
Bryan Brattlof6d138132022-12-19 14:29:50 -0600386
387At this point you should have every binary needed initialize both the
388wakeup and main domain and to boot to the U-Boot prompt
389
390**Main Domain Bootloader**
391
Neha Malcom Francis507be122023-07-22 00:14:43 +0530392 | `tispl.bin` for HS devices or `tispl.bin_unsigned` for GP devices
393 | `u-boot.img` for HS devices or `u-boot.img_unsigned` for GP devices
Manorit Chawdhryce7a62f2023-07-14 11:22:29 +0530394
Jonathan Humphreys43d44fa2024-06-21 15:17:06 -0500395Capsules
396--------
397
398Most K3 boards have support for UEFI capsule update via capsule-on-disk
399functionality. Check the ``CONFIG_EFI_CAPSULE_ON_DISK`` config option for
400the board under question to verify. If configured, capsules for each of the
401binaries above are automatically generated as part of the binary's build.
402They are named `<binary>-capsule.bin`. For example, the capsule for
403`u-boot.img` would be called `uboot-capsule.bin`.
404
405See :ref:`uefi_capsule_update_ref` for more information on U-Boot's support
406for capsule update and how they are applied.
407
408Each board defines the capsules generated, including where those capsules
409are applied. See the ``update_info`` definition for a board, typically
410found at `board/ti/<board>/evm.c`. For example, `board/ti/am62x/evm.c`.
411Usually, if the board has OSPI flash, the capsules will be applied there,
412else the boot partition of the eMMC device.
413
414Once applied, the board will have U-Boot binaries in on-board non-volatile
415storage. To start booting from that storage, set the bootmode pins
416accordingly. Future updates can be performed by using the capsules
417generated from the corresponding U-Boot builds.
418
Manorit Chawdhryf64b3bd2023-12-29 16:16:32 +0530419FIT signature signing
Manorit Chawdhryce7a62f2023-07-14 11:22:29 +0530420---------------------
421
Manorit Chawdhryf64b3bd2023-12-29 16:16:32 +0530422K3 platforms have FIT signature signing enabled by default on their primary
423platforms. Here we'll take an example for creating FIT Image for J721E platform
Manorit Chawdhryce7a62f2023-07-14 11:22:29 +0530424and the same can be extended to other platforms
425
Manorit Chawdhryf64b3bd2023-12-29 16:16:32 +0530426Pre-requisites:
Manorit Chawdhryce7a62f2023-07-14 11:22:29 +0530427
Manorit Chawdhryf64b3bd2023-12-29 16:16:32 +0530428* U-boot build (:ref:`U-boot build <k3_rst_include_start_build_steps_spl_r5>`)
429* Linux Image and Linux DTB prebuilt
430
431Describing FIT source
432^^^^^^^^^^^^^^^^^^^^^
433
434FIT Image is a packed structure containing binary blobs and configurations.
435The Kernel FIT Image that we have has Kernel Image, DTB and the DTBOs. It
436supports packing multiple images and configurations that allow you to
437choose any configuration at runtime to boot from.
438
439.. code-block::
Manorit Chawdhryce7a62f2023-07-14 11:22:29 +0530440
441 /dts-v1/;
442
443 / {
Manorit Chawdhryf64b3bd2023-12-29 16:16:32 +0530444 description = "FIT Image description";
445 #address-cells = <1>;
Manorit Chawdhryce7a62f2023-07-14 11:22:29 +0530446
Manorit Chawdhryf64b3bd2023-12-29 16:16:32 +0530447 images {
448 [image-1]
449 [image-2]
450 [fdt-1]
451 [fdt-2]
452 }
Manorit Chawdhryce7a62f2023-07-14 11:22:29 +0530453
Manorit Chawdhryf64b3bd2023-12-29 16:16:32 +0530454 configurations {
455 default = <conf-1>
456 [conf-1: image-1,fdt-1]
457 [conf-2: image-2,fdt-1]
458 }
459 }
Manorit Chawdhryce7a62f2023-07-14 11:22:29 +0530460
Manorit Chawdhryf64b3bd2023-12-29 16:16:32 +0530461* Sample Images
462
463.. code-block::
Manorit Chawdhryce7a62f2023-07-14 11:22:29 +0530464
Manorit Chawdhryf64b3bd2023-12-29 16:16:32 +0530465 kernel-1 {
466 description = "Linux kernel";
467 data = /incbin/("linux.bin");
468 type = "kernel";
469 arch = "arm64";
470 os = "linux";
471 compression = "gzip";
472 load = <0x81000000>;
473 entry = <0x81000000>;
474 hash-1 {
475 algo = "sha512";
Manorit Chawdhryce7a62f2023-07-14 11:22:29 +0530476 };
477 };
Manorit Chawdhryf64b3bd2023-12-29 16:16:32 +0530478 fdt-ti_k3-j721e-common-proc-board.dtb {
479 description = "Flattened Device Tree blob";
480 data = /incbin/("arch/arm64/boot/dts/ti/k3-j721e-common-proc-board.dtb");
481 type = "flat_dt";
482 arch = "arm64";
483 compression = "none";
484 load = <0x83000000>;
485 hash-1 {
486 algo = "sha512";
487 };
488 };
489 # Optional images
490 fdt-ti_k3-j721e-evm-virt-mac-client.dtbo {
491 description = "Flattened Device Tree blob";
492 data = /incbin/("arch/arm64/boot/dts/ti/k3-j721e-evm-virt-mac-client.dtbo");
493 type = "flat_dt";
494 arch = "arm64";
495 compression = "none";
496 load = <0x83080000>;
497 hash-1 {
498 algo = "sha512";
499 };
500 };
501
502.. note::
503
504 Change the path in data variables to point to the respective files in your
505 local machine. For e.g change "linux.bin" to "<path-to-kernel-image>".
Manorit Chawdhryce7a62f2023-07-14 11:22:29 +0530506
Manorit Chawdhryf64b3bd2023-12-29 16:16:32 +0530507For enabling usage of FIT signature, add the signature node to the
508corresponding configuration node as follows.
Manorit Chawdhryce7a62f2023-07-14 11:22:29 +0530509
Manorit Chawdhryf64b3bd2023-12-29 16:16:32 +0530510* Sample Configurations
Manorit Chawdhryce7a62f2023-07-14 11:22:29 +0530511
Manorit Chawdhryf64b3bd2023-12-29 16:16:32 +0530512.. code-block::
513
514 conf-ti_k3-j721e-common-proc-board.dtb {
515 description = "Linux kernel, FDT blob";
516 fdt = "fdt-ti_k3-j721e-common-proc-board.dtb";
517 kernel = "kernel-1";
518 signature-1 {
519 algo = "sha512,rsa4096";
520 key-name-hint = "custMpk";
521 sign-images = "kernel", "fdt";
522 };
523 };
524 # Optional configurations
525 conf-ti_k3-j721e-evm-virt-mac-client.dtbo {
526 description = "FDTO blob";
527 fdt = "fdt-ti_k3-j721e-evm-virt-mac-client.dtbo";
528
529 signature-1 {
530 algo = "sha512,rsa4096";
531 key-name-hint = "custMpk";
532 sign-images = "fdt";
533 };
534 };
535
536Specify all images you need the signature to authenticate as a part of
537sign-images. The key-name-hint needs to be changed if you are using some
538other key other than the TI dummy key that we are using for this example.
539It should be the name of the file containing the keys.
Manorit Chawdhryce7a62f2023-07-14 11:22:29 +0530540
Nishanth Menonb7ee22f2023-07-27 13:58:48 -0500541.. note::
Manorit Chawdhryce7a62f2023-07-14 11:22:29 +0530542
Manorit Chawdhryf64b3bd2023-12-29 16:16:32 +0530543 Generating new set of keys:
Manorit Chawdhryce7a62f2023-07-14 11:22:29 +0530544
Manorit Chawdhryf64b3bd2023-12-29 16:16:32 +0530545 .. prompt:: bash $
Manorit Chawdhryce7a62f2023-07-14 11:22:29 +0530546
Manorit Chawdhryf64b3bd2023-12-29 16:16:32 +0530547 mkdir keys
548 openssl genpkey -algorithm RSA -out keys/dev.key \
549 -pkeyopt rsa_keygen_bits:4096 -pkeyopt rsa_keygen_pubexp:65537
550 openssl req -batch -new -x509 -key keys/dev.key -out keys/dev.crt
Manorit Chawdhryce7a62f2023-07-14 11:22:29 +0530551
Manorit Chawdhryf64b3bd2023-12-29 16:16:32 +0530552Generating the fitImage
553^^^^^^^^^^^^^^^^^^^^^^^
Manorit Chawdhryce7a62f2023-07-14 11:22:29 +0530554
Manorit Chawdhryf64b3bd2023-12-29 16:16:32 +0530555.. note::
556
557 For signing a secondary platform like SK boards, you'll require
558 additional steps
Manorit Chawdhryce7a62f2023-07-14 11:22:29 +0530559
Manorit Chawdhryf64b3bd2023-12-29 16:16:32 +0530560 - Change the CONFIG_DEFAULT_DEVICE_TREE
Manorit Chawdhryce7a62f2023-07-14 11:22:29 +0530561
Manorit Chawdhryf64b3bd2023-12-29 16:16:32 +0530562 For e.g
Manorit Chawdhryce7a62f2023-07-14 11:22:29 +0530563
Manorit Chawdhryf64b3bd2023-12-29 16:16:32 +0530564 .. code-block::
Manorit Chawdhryce7a62f2023-07-14 11:22:29 +0530565
Manorit Chawdhryf64b3bd2023-12-29 16:16:32 +0530566 diff --git a/configs/j721e_evm_a72_defconfig b/configs/j721e_evm_a72_defconfig
567 index a5c1df7e0054..6d0126d955ef 100644
568 --- a/configs/j721e_evm_a72_defconfig
569 +++ b/configs/j721e_evm_a72_defconfig
570 @@ -13,7 +13,7 @@ CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0x80480000
571 CONFIG_ENV_SIZE=0x20000
572 CONFIG_DM_GPIO=y
573 CONFIG_SPL_DM_SPI=y
574 -CONFIG_DEFAULT_DEVICE_TREE="k3-j721e-common-proc-board"
575 +CONFIG_DEFAULT_DEVICE_TREE="k3-j721e-sk"
576 CONFIG_SPL_TEXT_BASE=0x80080000
577 CONFIG_DM_RESET=y
578 CONFIG_SPL_MMC=y
Manorit Chawdhryce7a62f2023-07-14 11:22:29 +0530579
Manorit Chawdhryf64b3bd2023-12-29 16:16:32 +0530580 - Change the binman nodes to package u-boot.dtb for the correct set of platform
Manorit Chawdhryce7a62f2023-07-14 11:22:29 +0530581
Manorit Chawdhryf64b3bd2023-12-29 16:16:32 +0530582 For e.g
Manorit Chawdhryce7a62f2023-07-14 11:22:29 +0530583
Manorit Chawdhryf64b3bd2023-12-29 16:16:32 +0530584 .. code-block::
Manorit Chawdhryce7a62f2023-07-14 11:22:29 +0530585
Manorit Chawdhryf64b3bd2023-12-29 16:16:32 +0530586 diff --git a/arch/arm/dts/k3-j721e-binman.dtsi b/arch/arm/dts/k3-j721e-binman.dtsi
587 index 673be646b1e3..752fa805fe8d 100644
588 --- a/arch/arm/dts/k3-j721e-binman.dtsi
589 +++ b/arch/arm/dts/k3-j721e-binman.dtsi
590 @@ -299,8 +299,8 @@
591 #define SPL_J721E_SK_DTB "spl/dts/k3-j721e-sk.dtb"
Manorit Chawdhryce7a62f2023-07-14 11:22:29 +0530592
Manorit Chawdhryf64b3bd2023-12-29 16:16:32 +0530593 #define UBOOT_NODTB "u-boot-nodtb.bin"
594 -#define J721E_EVM_DTB "u-boot.dtb"
595 -#define J721E_SK_DTB "arch/arm/dts/k3-j721e-sk.dtb"
596 +#define J721E_EVM_DTB "arch/arm/dts/k3-j721e-common-proc-board.dtb"
597 +#define J721E_SK_DTB "u-boot.dtb"
Manorit Chawdhryce7a62f2023-07-14 11:22:29 +0530598
Manorit Chawdhryf64b3bd2023-12-29 16:16:32 +0530599This step will embed the public key in the u-boot.dtb file that was already
600built during the initial u-boot build.
Manorit Chawdhryce7a62f2023-07-14 11:22:29 +0530601
Manorit Chawdhryf64b3bd2023-12-29 16:16:32 +0530602.. prompt:: bash $
Manorit Chawdhryce7a62f2023-07-14 11:22:29 +0530603
Manorit Chawdhryf64b3bd2023-12-29 16:16:32 +0530604 mkimage -r -f fitImage.its -k $UBOOT_PATH/board/ti/keys -K $UBOOT_PATH/build/$ARMV8/dts/dt.dtb fitImage
Manorit Chawdhryce7a62f2023-07-14 11:22:29 +0530605
Manorit Chawdhryf64b3bd2023-12-29 16:16:32 +0530606.. note::
Manorit Chawdhryce7a62f2023-07-14 11:22:29 +0530607
Manorit Chawdhryf64b3bd2023-12-29 16:16:32 +0530608 If you have another set of keys then change the -k argument to point to
609 the folder where your keys are present, the build requires the presence
610 of both .key and .crt file.
611
612Build u-boot again
613^^^^^^^^^^^^^^^^^^
614
615The updated u-boot.dtb needs to be packed in u-boot.img for authentication
616so rebuild U-boot ARMV8 without changing any parameters.
617Refer (:ref:`U-boot ARMV8 build <k3_rst_include_start_build_steps_uboot>`)
Manorit Chawdhryce7a62f2023-07-14 11:22:29 +0530618
619.. note::
620
Manorit Chawdhryf64b3bd2023-12-29 16:16:32 +0530621 The devices now also have distroboot enabled so if the FIT image doesn't
622 work then the fallback to normal distroboot will be there on HS devices.
623 This will need to be explicitly disabled by changing the boot_targets to
624 disallow fallback during testing.
Manorit Chawdhryce7a62f2023-07-14 11:22:29 +0530625
626Saving environment
627------------------
628
629SAVEENV is disabled by default and for the new flow uses Uenv.txt as the default
630way for saving the environments. This has been done as Uenv.txt is more granular
631then the saveenv command and can be used across various bootmodes too.
632
633**Writing to MMC/EMMC**
634
Nishanth Menon740c41c2023-11-02 23:40:25 -0500635.. prompt:: bash =>
Manorit Chawdhryce7a62f2023-07-14 11:22:29 +0530636
Nishanth Menon55fbcae2023-08-24 10:40:36 -0500637 env export -t $loadaddr <list of variables>
638 fatwrite mmc ${mmcdev} ${loadaddr} ${bootenvfile} ${filesize}
Manorit Chawdhryce7a62f2023-07-14 11:22:29 +0530639
640**Reading from MMC/EMMC**
641
642By default run envboot will read it from the MMC/EMMC partition ( based on
643mmcdev) and set the environments.
644
645If manually needs to be done then the environment can be read from the
646filesystem and then imported
647
Nishanth Menon740c41c2023-11-02 23:40:25 -0500648.. prompt:: bash =>
Manorit Chawdhryce7a62f2023-07-14 11:22:29 +0530649
Nishanth Menon55fbcae2023-08-24 10:40:36 -0500650 fatload mmc ${mmcdev} ${loadaddr} ${bootenvfile}
651 env import -t ${loadaddr} ${filesize}
Jason Kacinesb0fdee92023-08-03 01:29:22 -0500652
653.. _k3_rst_refer_openocd:
654
655Common Debugging environment - OpenOCD
656--------------------------------------
657
658This section will show you how to connect a board to `OpenOCD
659<https://openocd.org/>`_ and load the SPL symbols for debugging with
660a K3 generation device. To follow this guide, you must build custom
661u-boot binaries, start your board from a boot media such as an SD
662card, and use an OpenOCD environment. This section uses generic
663examples, though you can apply these instructions to any supported K3
664generation device.
665
666The overall structure of this setup is in the following figure.
667
668.. image:: img/openocd-overview.svg
Nishanth Menon5746e032023-08-22 11:40:56 -0500669 :alt: Overview of OpenOCD setup.
Jason Kacinesb0fdee92023-08-03 01:29:22 -0500670
671.. note::
672
673 If you find these instructions useful, please consider `donating
674 <https://openocd.org/pages/donations.html>`_ to OpenOCD.
675
676Step 1: Download and install OpenOCD
677^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
678
679To get started, it is more convenient if the distribution you
680use supports OpenOCD by default. Follow the instructions in the
681`getting OpenOCD <https://openocd.org/pages/getting-openocd.html>`_
682documentation to pick the installation steps appropriate to your
683environment. Some references to OpenOCD documentation:
684
685* `OpenOCD User Guide <https://openocd.org/doc/html/index.html>`_
686* `OpenOCD Developer's Guide <https://openocd.org/doc/doxygen/html/index.html>`_
687
688Refer to the release notes corresponding to the `OpenOCD version
689<https://github.com/openocd-org/openocd/releases>`_ to ensure
690
691* Processor support: In general, processor support shouldn't present
692 any difficulties since OpenOCD provides solid support for both ARMv8
693 and ARMv7.
694* SoC support: When working with System-on-a-Chip (SoC), the support
695 usually comes as a TCL config file. It is vital to ensure the correct
696 version of OpenOCD or to use the TCL files from the latest release or
697 the one mentioned.
698* Board or the JTAG adapter support: In most cases, board support is
699 a relatively easy problem if the board has a JTAG pin header. All
700 you need to do is ensure that the adapter you select is compatible
701 with OpenOCD. Some boards come with an onboard JTAG adapter that
702 requires a USB cable to be plugged into the board, in which case, it
703 is vital to ensure that the JTAG adapter is supported. Fortunately,
704 almost all TI K3 SK/EVMs come with TI's XDS110, which has out of the
705 box support by OpenOCD. The board-specific documentation will
706 cover the details and any adapter/dongle recommendations.
707
Nishanth Menon740c41c2023-11-02 23:40:25 -0500708.. prompt:: bash $
Jason Kacinesb0fdee92023-08-03 01:29:22 -0500709
710 openocd -v
711
712.. note::
713
714 OpenOCD version 0.12.0 is usually required to connect to most K3
715 devices. If your device is only supported by a newer version than the
716 one provided by your distribution, you may need to build it from the source.
717
718Building OpenOCD from source
719""""""""""""""""""""""""""""
720
721The dependency package installation instructions below are for Debian
722systems, but equivalent instructions should exist for systems with
723other package managers. Please refer to the `OpenOCD Documentation
724<https://openocd.org/>`_ for more recent installation steps.
725
Nishanth Menon740c41c2023-11-02 23:40:25 -0500726.. prompt:: bash $
Jason Kacinesb0fdee92023-08-03 01:29:22 -0500727
Nishanth Menon55fbcae2023-08-24 10:40:36 -0500728 # Check the packages to be installed: needs deb-src in sources.list
729 sudo apt build-dep openocd
730 # The following list is NOT complete - please check the latest
731 sudo apt-get install libtool pkg-config texinfo libusb-dev \
Jason Kacinesb0fdee92023-08-03 01:29:22 -0500732 libusb-1.0.0-dev libftdi-dev libhidapi-dev autoconf automake
Nishanth Menon55fbcae2023-08-24 10:40:36 -0500733 git clone https://github.com/openocd-org/openocd.git openocd
734 cd openocd
735 git submodule init
736 git submodule update
737 ./bootstrap
738 ./configure --prefix=/usr/local/
739 make -j`nproc`
740 sudo make install
Jason Kacinesb0fdee92023-08-03 01:29:22 -0500741
742.. note::
743
744 The example above uses the GitHub mirror site. See
745 `git repo information <https://openocd.org/doc/html/Developers.html#OpenOCD-Git-Repository>`_
746 information to pick the official git repo.
747 If a specific version is desired, select the version using `git checkout tag`.
748
749Installing OpenOCD udev rules
750"""""""""""""""""""""""""""""
751
752The step is not necessary if the distribution supports the OpenOCD, but
753if building from a source, ensure that the udev rules are installed
754correctly to ensure a sane system.
755
Nishanth Menon740c41c2023-11-02 23:40:25 -0500756.. prompt:: bash $
Jason Kacinesb0fdee92023-08-03 01:29:22 -0500757
758 # Go to the OpenOCD source directory
Nishanth Menon55fbcae2023-08-24 10:40:36 -0500759 cd openocd
760 Copy the udev rules to the correct system location
761 sudo cp ./contrib/60-openocd.rules \
Jonathan Humphreys27fd4982023-08-22 13:49:03 -0500762 ./src/jtag/drivers/libjaylink/contrib/99-libjaylink.rules \
Jason Kacinesb0fdee92023-08-03 01:29:22 -0500763 /etc/udev/rules.d/
764 # Get Udev to load the new rules up
Nishanth Menon55fbcae2023-08-24 10:40:36 -0500765 sudo udevadm control --reload-rules
Jason Kacinesb0fdee92023-08-03 01:29:22 -0500766 # Use the new rules on existing connected devices
Nishanth Menon55fbcae2023-08-24 10:40:36 -0500767 sudo udevadm trigger
Jason Kacinesb0fdee92023-08-03 01:29:22 -0500768
769Step 2: Setup GDB
770^^^^^^^^^^^^^^^^^
771
772Most systems come with gdb-multiarch package.
773
Nishanth Menon740c41c2023-11-02 23:40:25 -0500774.. prompt:: bash $
Jason Kacinesb0fdee92023-08-03 01:29:22 -0500775
776 # Install gdb-multiarch package
Nishanth Menon55fbcae2023-08-24 10:40:36 -0500777 sudo apt-get install gdb-multiarch
Jason Kacinesb0fdee92023-08-03 01:29:22 -0500778
779Though using GDB natively is normal, developers with interest in using IDE
780may find a few of these interesting:
781
782* `gdb-dashboard <https://github.com/cyrus-and/gdb-dashboard>`_
783* `gef <https://github.com/hugsy/gef>`_
784* `peda <https://github.com/longld/peda>`_
785* `pwndbg <https://github.com/pwndbg/pwndbg>`_
786* `voltron <https://github.com/snare/voltron>`_
787* `ddd <https://www.gnu.org/software/ddd/>`_
788* `vscode <https://www.justinmklam.com/posts/2017/10/vscode-debugger-setup/>`_
789* `vim conque-gdb <https://github.com/vim-scripts/Conque-GDB>`_
790* `emacs realgud <https://github.com/realgud/realgud/wiki/gdb-notes>`_
791* `Lauterbach IDE <https://www2.lauterbach.com/pdf/backend_gdb.pdf>`_
792
793.. warning::
794 LLDB support for OpenOCD is still a work in progress as of this writing.
795 Using GDB is probably the safest option at this point in time.
796
797Step 3: Connect board to PC
798^^^^^^^^^^^^^^^^^^^^^^^^^^^
799There are few patterns of boards in the ecosystem
800
801.. k3_rst_include_start_openocd_connect_XDS110
802
803**Integrated JTAG adapter/dongle**: The board has a micro-USB connector labelled
804XDS110 USB or JTAG. Connect a USB cable to the board to the mentioned port.
805
806.. note::
807
808 There are multiple USB ports on a typical board, So, ensure you have read
809 the user guide for the board and confirmed the silk screen label to ensure
810 connecting to the correct port.
811
812.. k3_rst_include_end_openocd_connect_XDS110
813
814.. k3_rst_include_start_openocd_connect_cti20
815
816**cTI20 connector**: The TI's `cTI20
817<https://software-dl.ti.com/ccs/esd/documents/xdsdebugprobes/emu_JTAG_connectors.html#cti-20-pin-header-information>`_ connector
818is probably the most prevelant on TI platforms. Though many
819TI boards have an onboard XDS110, cTI20 connector is usually
820provided as an alternate scheme to connect alternatives such
821as `Lauterbach <https://www.lauterbach.com/>`_ or `XDS560
822<https://www.ti.com/tool/TMDSEMU560V2STM-U>`_.
823
824To debug on these boards, the following combinations is suggested:
825
826* `TUMPA <https://www.diygadget.com/JTAG-cables-and-microcontroller-programmers/tiao-usb-multi-protocol-adapter-JTAG-spi-i2c-serial>`_
827 or `equivalent dongles supported by OpenOCD. <https://openocd.org/doc/html/Debug-Adapter-Hardware.html#Debug-Adapter-Hardware>`_
828* Cable such as `Tag-connect ribbon cable <https://www.tag-connect.com/product/20-pin-cortex-ribbon-cable-4-length-with-50-mil-connectors>`_
829* Adapter to convert cTI20 to ARM20 such as those from
830 `Segger <https://www.segger.com/products/debug-probes/j-link/accessories/adapters/ti-cti-20-adapter/>`_
831 or `Lauterbach LA-3780 <https://www.lauterbach.com/ad3780.html>`_
832 Or optionally, if you have manufacturing capability then you could try
833 `BeagleBone JTAG Adapter <https://github.com/mmorawiec/BeagleBone-Black-JTAG-Adapters>`_
834
835.. warning::
836 XDS560 and Lauterbach are proprietary solutions and is not supported by
837 OpenOCD.
838 When purchasing an off the shelf adapter/dongle, you do want to be careful
839 about the signalling though. Please
840 `read for additional info <https://software-dl.ti.com/ccs/esd/xdsdebugprobes/emu_JTAG_connectors.html>`_.
841
842.. k3_rst_include_end_openocd_connect_cti20
843
844.. k3_rst_include_start_openocd_connect_tag_connect
845
846**Tag-Connect**: `Tag-Connect <https://www.tag-connect.com/>`_
847pads on the boards which require special cable. Please check the documentation
848to `identify <https://www.tag-connect.com/info/legs-or-no-legs>`_ if "legged"
849or "no-leg" version of the cable is appropriate for the board.
850
851To debug on these boards, you will need:
852
853* `TUMPA <https://www.diygadget.com/JTAG-cables-and-microcontroller-programmers/tiao-usb-multi-protocol-adapter-JTAG-spi-i2c-serial>`_
854 or `equivalent dongles supported by OpenOCD <https://openocd.org/doc/html/Debug-Adapter-Hardware.html#Debug-Adapter-Hardware>`_.
855* Tag-Connect cable appropriate to the board such as
856 `TC2050-IDC-NL <https://www.tag-connect.com/product/TC2050-IDC-NL-10-pin-no-legs-cable-with-ribbon-connector>`_
857* In case of no-leg, version, a
858 `retaining clip <https://www.tag-connect.com/product/tc2050-clip-3pack-retaining-clip>`_
859* Tag-Connect to ARM20
860 `adapter <https://www.tag-connect.com/product/tc2050-arm2010-arm-20-pin-to-tc2050-adapter>`_
861
862.. note::
863 You can optionally use a 3d printed solution such as
864 `Protective cap <https://www.thingiverse.com/thing:3025584>`_ or
865 `clip <https://www.thingiverse.com/thing:3035278>`_ to replace
866 the retaining clip.
867
868.. warning::
869 With the Tag-Connect to ARM20 adapter, Please solder the "Trst" signal for
870 connection to work.
871
872.. k3_rst_include_end_openocd_connect_tag_connect
873
874Debugging with OpenOCD
875^^^^^^^^^^^^^^^^^^^^^^
876
877Debugging U-Boot is different from debugging regular user space
878applications. The bootloader initialization process involves many boot
879media and hardware configuration operations. For K3 devices, there
880are also interactions with security firmware. While reloading the
881"elf" file works through GDB, developers must be mindful of cascading
882initialization's potential consequences.
883
884Consider the following code change:
885
886.. code-block:: diff
887
888 --- a/file.c 2023-07-29 10:55:29.647928811 -0500
889 +++ b/file.c 2023-07-29 10:55:46.091856816 -0500
890 @@ -1,3 +1,3 @@
891 val = readl(reg);
892 -val |= 0x2;
893 +val |= 0x1;
894 writel(val, reg);
895
896Re-running the elf file with the above change will result in the
897register setting 0x3 instead of the intended 0x1. There are other
898hardware blocks which may not behave very well with a re-initialization
899without proper shutdown.
900
901To help narrow the debug down, it is usually simpler to use the
902standard boot media to get to the bootloader and debug only in the area
903of interest.
904
905In general, to debug u-boot spl/u-boot with OpenOCD there are three steps:
906
907* Modify the code adding a loop to allow the debugger to attach
908 near the point of interest. Boot up normally to stop at the loop.
909* Connect with OpenOCD and step out of the loop.
910* Step through the code to find the root of issue.
911
912Typical debugging involves a few iterations of the above sequence.
913Though most bootloader developers like to use printf to debug,
914debug with JTAG tends to be most efficient since it is possible to
915investigate the code flow and inspect hardware registers without
916repeated iterations.
917
918Code modification
919"""""""""""""""""
920
921* **start.S**: Adding an infinite while loop at the very entry of
922 U-Boot. For this, look for the corresponding start.S entry file.
923 This is usually only required when debugging some core SoC or
924 processor related function. For example: arch/arm/cpu/armv8/start.S or
925 arch/arm/cpu/armv7/start.S
926
927.. code-block:: diff
928
929 diff --git a/arch/arm/cpu/armv7/start.S b/arch/arm/cpu/armv7/start.S
930 index 69e281b086..744929e825 100644
931 --- a/arch/arm/cpu/armv7/start.S
932 +++ b/arch/arm/cpu/armv7/start.S
933 @@ -37,6 +37,8 @@
934 #endif
935
936 reset:
937 +dead_loop:
938 + b dead_loop
939 /* Allow the board to save important registers */
940 b save_boot_params
941 save_boot_params_ret:
942
943* **board_init_f**: Adding an infinite while loop at the board entry
944 function. In many cases, it is important to debug the boot process if
945 any changes are made for board-specific applications. Below is a step
946 by step process for debugging the boot SPL or Armv8 SPL:
947
948 To debug the boot process in either domain, we will first
949 add a modification to the code we would like to debug.
950 In this example, we will debug ``board_init_f`` inside
951 ``arch/arm/mach-k3/{soc}_init.c``. Since some sections of U-Boot
952 will be executed multiple times during the bootup process of K3
Jonathan Humphreys27fd4982023-08-22 13:49:03 -0500953 devices, we will need to include either ``CONFIG_ARM64`` or
Jason Kacinesb0fdee92023-08-03 01:29:22 -0500954 ``CONFIG_CPU_V7R`` to catch the CPU at the desired place during the
955 bootup process (Main or Wakeup domains). For example, modify the
956 file as follows (depending on need):
957
958.. code-block:: c
959
960 void board_init_f(ulong dummy)
961 {
962 .
963 .
964 /* Code to run on the R5F (Wakeup/Boot Domain) */
965 if (IS_ENABLED(CONFIG_CPU_V7R)) {
966 volatile int x = 1;
967 while(x) {};
968 }
969 ...
970 /* Code to run on the ARMV8 (Main Domain) */
Jonathan Humphreys27fd4982023-08-22 13:49:03 -0500971 if (IS_ENABLED(CONFIG_ARM64)) {
Jason Kacinesb0fdee92023-08-03 01:29:22 -0500972 volatile int x = 1;
973 while(x) {};
974 }
975 .
976 .
977 }
978
979Connecting with OpenOCD for a debug session
980"""""""""""""""""""""""""""""""""""""""""""
981
982Startup OpenOCD to debug the platform as follows:
983
984* **Integrated JTAG interface**: If the evm has a debugger such as
985 XDS110 inbuilt, there is typically an evm board support added and a
986 cfg file will be available.
987
988.. k3_rst_include_start_openocd_cfg_XDS110
989
Nishanth Menon740c41c2023-11-02 23:40:25 -0500990.. prompt:: bash $
Jason Kacinesb0fdee92023-08-03 01:29:22 -0500991
992 openocd -f board/{board_of_choice}.cfg
993
994.. k3_rst_include_end_openocd_cfg_XDS110
995
996.. k3_rst_include_start_openocd_cfg_external_intro
997
998* **External JTAG adapter/interface**: In other cases, where an
999 adapter/dongle is used, a simple cfg file can be created to integrate the
1000 SoC and adapter information. See `supported TI K3 SoCs
1001 <https://github.com/openocd-org/openocd/blob/master/tcl/target/ti_k3.cfg#L59>`_
1002 to decide if the SoC is supported or not.
1003
Nishanth Menon740c41c2023-11-02 23:40:25 -05001004.. prompt:: bash $
Jason Kacinesb0fdee92023-08-03 01:29:22 -05001005
1006 openocd -f openocd_connect.cfg
1007
1008.. k3_rst_include_end_openocd_cfg_external_intro
1009
1010 For example, with BeaglePlay (AM62X platform), the openocd_connect.cfg:
1011
1012.. code-block:: tcl
1013
1014 # TUMPA example:
1015 # http://www.tiaowiki.com/w/TIAO_USB_Multi_Protocol_Adapter_User's_Manual
1016 source [find interface/ftdi/tumpa.cfg]
1017
1018 transport select jtag
1019
1020 # default JTAG configuration has only SRST and no TRST
1021 reset_config srst_only srst_push_pull
1022
1023 # delay after SRST goes inactive
1024 adapter srst delay 20
1025
1026 if { ![info exists SOC] } {
1027 # Set the SoC of interest
1028 set SOC am625
1029 }
1030
1031 source [find target/ti_k3.cfg]
1032
1033 ftdi tdo_sample_edge falling
1034
1035 # Speeds for FT2232H are in multiples of 2, and 32MHz is tops
1036 # max speed we seem to achieve is ~20MHz.. so we pick 16MHz
1037 adapter speed 16000
1038
1039Below is an example of the output of this command:
1040
1041.. code-block:: console
1042
1043 Info : Listening on port 6666 for tcl connections
1044 Info : Listening on port 4444 for telnet connections
1045 Info : XDS110: connected
1046 Info : XDS110: vid/pid = 0451/bef3
1047 Info : XDS110: firmware version = 3.0.0.20
1048 Info : XDS110: hardware version = 0x002f
1049 Info : XDS110: connected to target via JTAG
1050 Info : XDS110: TCK set to 2500 kHz
1051 Info : clock speed 2500 kHz
1052 Info : JTAG tap: am625.cpu tap/device found: 0x0bb7e02f (mfg: 0x017 (Texas Instruments), part: 0xbb7e, ver: 0x0)
1053 Info : starting gdb server for am625.cpu.sysctrl on 3333
1054 Info : Listening on port 3333 for gdb connections
1055 Info : starting gdb server for am625.cpu.a53.0 on 3334
1056 Info : Listening on port 3334 for gdb connections
1057 Info : starting gdb server for am625.cpu.a53.1 on 3335
1058 Info : Listening on port 3335 for gdb connections
1059 Info : starting gdb server for am625.cpu.a53.2 on 3336
1060 Info : Listening on port 3336 for gdb connections
1061 Info : starting gdb server for am625.cpu.a53.3 on 3337
1062 Info : Listening on port 3337 for gdb connections
1063 Info : starting gdb server for am625.cpu.main0_r5.0 on 3338
1064 Info : Listening on port 3338 for gdb connections
1065 Info : starting gdb server for am625.cpu.gp_mcu on 3339
1066 Info : Listening on port 3339 for gdb connections
1067
1068.. note::
1069 Notice the default configuration is non-SMP configuration allowing
1070 for each of the core to be attached and debugged simultaneously.
1071 ARMv8 SPL/U-Boot starts up on cpu0 of a53/a72.
1072
1073.. k3_rst_include_start_openocd_cfg_external_gdb
1074
1075To debug using this server, use GDB directly or your preferred
1076GDB-based IDE. To start up GDB in the terminal, run the following
1077command.
1078
Nishanth Menon740c41c2023-11-02 23:40:25 -05001079.. prompt:: bash $
Jason Kacinesb0fdee92023-08-03 01:29:22 -05001080
1081 gdb-multiarch
1082
1083To connect to your desired core, run the following command within GDB:
1084
Nishanth Menon740c41c2023-11-02 23:40:25 -05001085.. prompt:: bash (gdb)
Jason Kacinesb0fdee92023-08-03 01:29:22 -05001086
1087 target extended-remote localhost:{port for desired core}
1088
1089To load symbols:
1090
1091.. warning::
1092
1093 SPL and U-Boot does a re-location of address compared to where it
1094 is loaded originally. This step takes place after the DDR size is
1095 determined from dt parsing. So, debugging can be split into either
1096 "before re-location" or "after re-location". Please refer to the
1097 file ''doc/README.arm-relocation'' to see how to grab the relocation
1098 address.
1099
1100* Prior to relocation:
1101
Nishanth Menon740c41c2023-11-02 23:40:25 -05001102.. prompt:: bash (gdb)
Jason Kacinesb0fdee92023-08-03 01:29:22 -05001103
1104 symbol-file {path to elf file}
1105
1106* After relocation:
1107
Nishanth Menon740c41c2023-11-02 23:40:25 -05001108.. prompt:: bash (gdb)
Jason Kacinesb0fdee92023-08-03 01:29:22 -05001109
1110 # Drop old symbol file
1111 symbol-file
1112 # Pick up new relocaddr
1113 add-symbol-file {path to elf file} {relocaddr}
1114
1115.. k3_rst_include_end_openocd_cfg_external_gdb
1116
1117In the above example of AM625,
1118
Nishanth Menon740c41c2023-11-02 23:40:25 -05001119.. prompt:: bash (gdb)
Jason Kacinesb0fdee92023-08-03 01:29:22 -05001120
1121 target extended-remote localhost:3338 <- R5F (Wakeup Domain)
1122 target extended-remote localhost:3334 <- A53 (Main Domain)
1123
1124The core can now be debugged directly within GDB using GDB commands or
1125if using IDE, as appropriate to the IDE.
1126
1127Stepping through the code
1128"""""""""""""""""""""""""
1129
1130`GDB TUI Commands
1131<https://sourceware.org/gdb/onlinedocs/gdb/TUI-Commands.html>`_ can
1132help set up the display more sensible for debug. Provide the name
1133of the layout that can be used to debug. For example, use the GDB
1134command ``layout src`` after loading the symbols to see the code and
1135breakpoints. To exit the debug loop added above, add any breakpoints
1136needed and run the following GDB commands to step out of the debug
1137loop set in the ``board_init_f`` function.
1138
Nishanth Menon740c41c2023-11-02 23:40:25 -05001139.. prompt:: bash (gdb)
Jason Kacinesb0fdee92023-08-03 01:29:22 -05001140
1141 set x = 0
1142 continue
1143
1144The platform has now been successfully setup to debug with OpenOCD
1145using GDB commands or a GDB-based IDE. See `OpenOCD documentation for
1146GDB <https://openocd.org/doc/html/GDB-and-OpenOCD.html>`_ for further
1147information.
1148
1149.. warning::
1150
1151 On the K3 family of devices, a watchdog timer within the DMSC is
1152 enabled by default by the ROM bootcode with a timeout of 3 minutes.
1153 The watchdog timer is serviced by System Firmware (SYSFW) or TI
1154 Foundational Security (TIFS) during normal operation. If debugging
1155 the SPL before the SYSFW is loaded, the watchdog timer will not get
1156 serviced automatically and the debug session will reset after 3
1157 minutes. It is recommended to start debugging SPL code only after
1158 the startup of SYSFW to avoid running into the watchdog timer reset.
1159
1160Miscellaneous notes with OpenOCD
1161^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
1162
1163Currently, OpenOCD does not support tracing for K3 platforms. Tracing
1164function could be beneficial if the bug in code occurs deep within
1165nested function and can optionally save developers major trouble of
1166stepping through a large quantity of code.