to after it has finished loading everything into internal SRAM.
.. image:: img/boot_flow_01.svg
+ :alt: Boot flow up to wakeup domain 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`
OP-TEE and the main domain's U-Boot SPL.
.. image:: img/boot_flow_02.svg
+ :alt: Boot flow up to main domain 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
finally prepare the main domain to run Linux.
.. image:: img/boot_flow_03.svg
+ :alt: Complete boot flow up to 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
| **source:** https://github.com/OP-TEE/optee_os.git
| **branch:** master
-* **TI Firmware (TIFS, DM, DSMC)**
+* **TI Firmware (TIFS, DM, SYSFW)**
| **source:** https://git.ti.com/git/processor-firmware/ti-linux-firmware.git
| **branch:** ti-linux-firmware
+.. note::
+
+ The TI Firmware required for functionality of the system can be
+ one of the following combination (see platform specific boot diagram for
+ further information as to which component runs on which processor):
+
+ * **TIFS** - TI Foundational Security Firmware - Consists of purely firmware
+ meant to run on the security enclave.
+ * **DM** - Device Management firmware also called TI System Control Interface
+ server (TISCI Server) - This component purely plays the role of managing
+ device resources such as power, clock, interrupts, dma etc. This firmware
+ runs on a dedicated or multi-use microcontroller outside the security
+ enclave.
+
+ OR
+
+ * **SYSFW** - System firmware - consists of both TIFS and DM both running on
+ the security enclave.
+
.. k3_rst_include_end_boot_sources
Build Procedure
.. k3_rst_include_end_common_env_vars_desc
.. k3_rst_include_start_common_env_vars_defn
-.. code-block:: bash
+.. prompt:: bash
- $ export CC32=arm-linux-gnueabihf-
- $ export CC64=aarch64-linux-gnu-
- $ export LNX_FW_PATH=path/to/ti-linux-firmware
- $ export TFA_PATH=path/to/trusted-firmware-a
- $ export OPTEE_PATH=path/to/optee_os
+ export CC32=arm-linux-gnueabihf-
+ export CC64=aarch64-linux-gnu-
+ export LNX_FW_PATH=path/to/ti-linux-firmware
+ export TFA_PATH=path/to/trusted-firmware-a
+ export OPTEE_PATH=path/to/optee_os
.. k3_rst_include_end_common_env_vars_defn
We will also need some common environment variables set up for the various
uses the split binary flow)
.. k3_rst_include_start_build_steps_spl_r5
-.. code-block:: bash
+.. prompt:: bash
- $ # inside u-boot source
- $ make $UBOOT_CFG_CORTEXR
- $ make CROSS_COMPILE=$CC32 BINMAN_INDIRS=$LNX_FW_PATH
+ # inside u-boot source
+ make $UBOOT_CFG_CORTEXR
+ make CROSS_COMPILE=$CC32 BINMAN_INDIRS=$LNX_FW_PATH
.. k3_rst_include_end_build_steps_spl_r5
At this point you should have all the needed binaries to boot the wakeup
application cores on the main domain.
.. k3_rst_include_start_build_steps_tfa
-.. code-block:: bash
+.. prompt:: bash
- $ # inside trusted-firmware-a source
- $ make CROSS_COMPILE=$CC64 ARCH=aarch64 PLAT=k3 SPD=opteed $TFA_EXTRA_ARGS \
- TARGET_BOARD=$TFA_BOARD
+ # inside trusted-firmware-a source
+ make CROSS_COMPILE=$CC64 ARCH=aarch64 PLAT=k3 SPD=opteed $TFA_EXTRA_ARGS \
+ TARGET_BOARD=$TFA_BOARD
.. k3_rst_include_end_build_steps_tfa
Typically all `j7*` devices will use `TARGET_BOARD=generic` or `TARGET_BOARD
using the TrustZone technology built into the core.
.. k3_rst_include_start_build_steps_optee
-.. code-block:: bash
+.. prompt:: bash
- $ # inside optee_os source
- $ make CROSS_COMPILE=$CC32 CROSS_COMPILE64=$CC64 CFG_ARM64_core=y $OPTEE_EXTRA_ARGS \
- PLATFORM=$OPTEE_PLATFORM
+ # inside optee_os source
+ make CROSS_COMPILE=$CC32 CROSS_COMPILE64=$CC64 CFG_ARM64_core=y $OPTEE_EXTRA_ARGS \
+ PLATFORM=$OPTEE_PLATFORM
.. k3_rst_include_end_build_steps_optee
4. Finally, after TF-A has initialized the main domain and OP-TEE has
64bit core in the main domain.
.. k3_rst_include_start_build_steps_uboot
-.. code-block:: bash
+.. prompt:: bash
- $ # inside u-boot source
- $ make $UBOOT_CFG_CORTEXA
- $ make CROSS_COMPILE=$CC64 BINMAN_INDIRS=$LNX_FW_PATH \
+ # inside u-boot source
+ make $UBOOT_CFG_CORTEXA
+ make CROSS_COMPILE=$CC64 BINMAN_INDIRS=$LNX_FW_PATH \
BL31=$TFA_PATH/build/k3/$TFA_BOARD/release/bl31.bin \
TEE=$OPTEE_PATH/out/arm-plat-k3/core/tee-raw.bin
.. k3_rst_include_end_build_steps_uboot
be passing to mkimage for signing the fitImage and embedding the key in
the u-boot dtb.
- .. code-block:: bash
+ .. prompt:: bash
mkimage -r -f fitImage.its -k $UBOOT_PATH/board/ti/keys -K
$UBOOT_PATH/build/a72/dts/dt.dtb
For signing a secondary platform, pass the -K parameter to that DTB
- .. code-block:: bash
+ .. prompt:: bash
mkimage -f fitImage.its -k $UBOOT_PATH/board/ti/keys -K
$UBOOT_PATH/build/a72/arch/arm/dts/k3-j721e-sk.dtb
**Writing to MMC/EMMC**
-.. code-block::
+.. prompt:: bash
+ :prompts: =>
- => env export -t $loadaddr <list of variables>
- => fatwrite mmc ${mmcdev} ${loadaddr} ${bootenvfile} ${filesize}
+ env export -t $loadaddr <list of variables>
+ fatwrite mmc ${mmcdev} ${loadaddr} ${bootenvfile} ${filesize}
**Reading from MMC/EMMC**
If manually needs to be done then the environment can be read from the
filesystem and then imported
-.. code-block::
+.. prompt:: bash
+ :prompts: =>
- => fatload mmc ${mmcdev} ${loadaddr} ${bootenvfile}
- => env import -t ${loadaddr} ${filesize}
+ fatload mmc ${mmcdev} ${loadaddr} ${bootenvfile}
+ env import -t ${loadaddr} ${filesize}
.. _k3_rst_refer_openocd:
The overall structure of this setup is in the following figure.
.. image:: img/openocd-overview.svg
+ :alt: Overview of OpenOCD setup.
.. note::
box support by OpenOCD. The board-specific documentation will
cover the details and any adapter/dongle recommendations.
-.. code-block:: bash
+.. prompt:: bash
openocd -v
other package managers. Please refer to the `OpenOCD Documentation
<https://openocd.org/>`_ for more recent installation steps.
-.. code-block:: bash
+.. prompt:: bash
- $ # Check the packages to be installed: needs deb-src in sources.list
- $ sudo apt build-dep openocd
- $ # The following list is NOT complete - please check the latest
- $ sudo apt-get install libtool pkg-config texinfo libusb-dev \
+ # Check the packages to be installed: needs deb-src in sources.list
+ sudo apt build-dep openocd
+ # The following list is NOT complete - please check the latest
+ sudo apt-get install libtool pkg-config texinfo libusb-dev \
libusb-1.0.0-dev libftdi-dev libhidapi-dev autoconf automake
- $ git clone https://github.com/openocd-org/openocd.git openocd
- $ cd openocd
- $ git submodule init
- $ git submodule update
- $ ./bootstrap
- $ ./configure --prefix=/usr/local/
- $ make -j`nproc`
- $ sudo make install
+ git clone https://github.com/openocd-org/openocd.git openocd
+ cd openocd
+ git submodule init
+ git submodule update
+ ./bootstrap
+ ./configure --prefix=/usr/local/
+ make -j`nproc`
+ sudo make install
.. note::
if building from a source, ensure that the udev rules are installed
correctly to ensure a sane system.
-.. code-block:: bash
+.. prompt:: bash
# Go to the OpenOCD source directory
- $ cd openocd
- # Copy the udev rules to the correct system location
- $ sudo cp ./contrib/60-openocd.rules \
- ./src/JTAG/drivers/libjaylink/contrib/99-libjaylink.rules \
+ cd openocd
+ Copy the udev rules to the correct system location
+ sudo cp ./contrib/60-openocd.rules \
+ ./src/jtag/drivers/libjaylink/contrib/99-libjaylink.rules \
/etc/udev/rules.d/
# Get Udev to load the new rules up
- $ sudo udevadm control --reload-rules
+ sudo udevadm control --reload-rules
# Use the new rules on existing connected devices
- $ sudo udevadm trigger
+ sudo udevadm trigger
Step 2: Setup GDB
^^^^^^^^^^^^^^^^^
Most systems come with gdb-multiarch package.
-.. code-block:: bash
+.. prompt:: bash
# Install gdb-multiarch package
- $ sudo apt-get install gdb-multiarch
+ sudo apt-get install gdb-multiarch
Though using GDB natively is normal, developers with interest in using IDE
may find a few of these interesting:
In this example, we will debug ``board_init_f`` inside
``arch/arm/mach-k3/{soc}_init.c``. Since some sections of U-Boot
will be executed multiple times during the bootup process of K3
- devices, we will need to include either ``CONFIG_CPU_ARM64`` or
+ devices, we will need to include either ``CONFIG_ARM64`` or
``CONFIG_CPU_V7R`` to catch the CPU at the desired place during the
bootup process (Main or Wakeup domains). For example, modify the
file as follows (depending on need):
}
...
/* Code to run on the ARMV8 (Main Domain) */
- if (IS_ENABLED(CONFIG_CPU_ARM64)) {
+ if (IS_ENABLED(CONFIG_ARM64)) {
volatile int x = 1;
while(x) {};
}
.. k3_rst_include_start_openocd_cfg_XDS110
-.. code-block:: bash
+.. prompt:: bash
openocd -f board/{board_of_choice}.cfg
<https://github.com/openocd-org/openocd/blob/master/tcl/target/ti_k3.cfg#L59>`_
to decide if the SoC is supported or not.
-.. code-block:: bash
+.. prompt:: bash
openocd -f openocd_connect.cfg
GDB-based IDE. To start up GDB in the terminal, run the following
command.
-.. code-block:: bash
+.. prompt:: bash
gdb-multiarch
projects / J-u-boot.git / blobdiff