| 123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221222223224225226227228229230231232233234235236237238239240241242243244245246247248249250251252253254255256257258259260261262263264265266267268269270271272273274275276277278279280281282283284285286287288289290291292293294295296297298299300301302303304305306307308309310311312313314315316317318319 |
- .. SPDX-License-Identifier: GPL-2.0+ OR BSD-3-Clause
- .. sectionauthor:: Neha Francis <n-francis@ti.com>
- AM65x Platforms
- ===============
- Introduction:
- -------------
- The AM65x family of SoCs is the first device family from K3 Multicore
- SoC architecture, targeted for broad market and industrial control with
- aim to meet the complex processing needs of modern embedded products.
- The device is built over three domains, each containing specific processing
- cores, voltage domains and peripherals:
- 1. Wake-up (WKUP) domain:
- * Device Management and Security Controller (DMSC)
- 2. Microcontroller (MCU) domain:
- * Dual Core ARM Cortex-R5F processor
- 3. MAIN domain:
- * Quad core 64-bit ARM Cortex-A53
- More info can be found in TRM: http://www.ti.com/lit/pdf/spruid7
- Platform information:
- * https://www.ti.com/tool/TMDX654GPEVM
- Boot Flow:
- ----------
- On AM65x family devices, ROM supports boot only via MCU(R5). This means that
- bootloader has to run on R5 core. In order to meet this constraint, and for
- the following reasons the boot flow is designed as mentioned:
- 1. Need to move away from R5 asap, so that we want to start *any*
- firmware on the R5 cores for example autosar can be loaded to receive CAN
- response and other safety operations to be started. This operation is
- very time critical and is applicable for all automotive use cases.
- 2. U-Boot on A53 should start other remotecores for various
- applications. This should happen before running Linux.
- 3. In production boot flow, we might not like to use full U-Boot,
- instead use Falcon boot flow to reduce boot time.
- .. image:: img/boot_diagram_am65.svg
- :alt: Boot flow diagram
- - Here DMSC acts as master and provides all the critical services. R5/A53
- requests DMSC to get these services done as shown in the above diagram.
- Sources:
- --------
- .. include:: k3.rst
- :start-after: .. k3_rst_include_start_boot_sources
- :end-before: .. k3_rst_include_end_boot_sources
- Build procedure:
- ----------------
- 0. Setup the environment variables:
- .. include:: k3.rst
- :start-after: .. k3_rst_include_start_common_env_vars_desc
- :end-before: .. k3_rst_include_end_common_env_vars_desc
- .. include:: k3.rst
- :start-after: .. k3_rst_include_start_board_env_vars_desc
- :end-before: .. k3_rst_include_end_board_env_vars_desc
- Set the variables corresponding to this platform:
- .. include:: k3.rst
- :start-after: .. k3_rst_include_start_common_env_vars_defn
- :end-before: .. k3_rst_include_end_common_env_vars_defn
- .. code-block:: bash
- $ export UBOOT_CFG_CORTEXR=am65x_evm_r5_defconfig
- $ export UBOOT_CFG_CORTEXA=am65x_evm_a53_defconfig
- $ export TFA_BOARD=generic
- $ # we dont use any extra TFA parameters
- $ unset TFA_EXTRA_ARGS
- $ export OPTEE_PLATFORM=k3-am65x
- $ # we dont use any extra OP-TEE parameters
- $ unset OPTEE_EXTRA_ARGS
- .. am65x_evm_rst_include_start_build_steps
- 1. Trusted Firmware-A:
- .. include:: k3.rst
- :start-after: .. k3_rst_include_start_build_steps_tfa
- :end-before: .. k3_rst_include_end_build_steps_tfa
- 2. OP-TEE:
- .. include:: k3.rst
- :start-after: .. k3_rst_include_start_build_steps_optee
- :end-before: .. k3_rst_include_end_build_steps_optee
- 3. U-Boot:
- * 3.1 R5:
- .. include:: k3.rst
- :start-after: .. k3_rst_include_start_build_steps_spl_r5
- :end-before: .. k3_rst_include_end_build_steps_spl_r5
- * 3.2 A53:
- .. include:: k3.rst
- :start-after: .. k3_rst_include_start_build_steps_uboot
- :end-before: .. k3_rst_include_end_build_steps_uboot
- .. am65x_evm_rst_include_end_build_steps
- Target Images
- --------------
- In order to boot we need tiboot3.bin, sysfw.itb, tispl.bin and u-boot.img.
- Each SoC variant (GP and HS) requires a different source for these files.
- - GP
- * tiboot3-am65x_sr2-gp-evm.bin, sysfw-am65x_sr2-gp-evm.itb from step 3.1
- * tispl.bin_unsigned, u-boot.img_unsigned from step 3.2
- - HS
- * tiboot3-am65x_sr2-hs-evm.bin, sysfw-am65x_sr2-hs-evm.itb from step 3.1
- * tispl.bin, u-boot.img from step 3.2
- Image formats:
- --------------
- - tiboot3.bin
- .. image:: img/no_multi_cert_tiboot3.bin.svg
- :alt: tiboot3.bin image format
- - tispl.bin
- .. image:: img/nodm_tispl.bin.svg
- :alt: tispl.bin image format
- - sysfw.itb
- .. image:: img/sysfw.itb.svg
- :alt: sysfw.itb image format
- eMMC:
- -----
- ROM supports booting from eMMC from boot0 partition offset 0x0
- Flashing images to eMMC:
- The following commands can be used to download tiboot3.bin, tispl.bin,
- u-boot.img, and sysfw.itb from an SD card and write them to the eMMC boot0
- partition at respective addresses.
- .. code-block:: text
- => mmc dev 0 1
- => fatload mmc 1 ${loadaddr} tiboot3.bin
- => mmc write ${loadaddr} 0x0 0x400
- => fatload mmc 1 ${loadaddr} tispl.bin
- => mmc write ${loadaddr} 0x400 0x1000
- => fatload mmc 1 ${loadaddr} u-boot.img
- => mmc write ${loadaddr} 0x1400 0x2000
- => fatload mmc 1 ${loadaddr} sysfw.itb
- => mmc write ${loadaddr} 0x3600 0x800
- To give the ROM access to the boot partition, the following commands must be
- used for the first time:
- .. code-block:: text
- => mmc partconf 0 1 1 1
- => mmc bootbus 0 1 0 0
- To create a software partition for the rootfs, the following command can be
- used:
- .. code-block:: text
- => gpt write mmc 0 ${partitions}
- eMMC layout:
- .. image:: img/emmc_am65x_evm_boot0.svg
- :alt: emmc boot partition layout
- Kernel image and DT are expected to be present in the /boot folder of rootfs.
- To boot kernel from eMMC, use the following commands:
- .. code-block:: text
- => setenv mmcdev 0
- => setenv bootpart 0
- => boot
- OSPI:
- -----
- ROM supports booting from OSPI from offset 0x0.
- Flashing images to OSPI:
- Below commands can be used to download tiboot3.bin, tispl.bin, u-boot.img,
- and sysfw.itb over tftp and then flash those to OSPI at their respective
- addresses.
- .. code-block:: text
- => sf probe
- => tftp ${loadaddr} tiboot3.bin
- => sf update $loadaddr 0x0 $filesize
- => tftp ${loadaddr} tispl.bin
- => sf update $loadaddr 0x80000 $filesize
- => tftp ${loadaddr} u-boot.img
- => sf update $loadaddr 0x280000 $filesize
- => tftp ${loadaddr} sysfw.itb
- => sf update $loadaddr 0x6C0000 $filesize
- Flash layout for OSPI:
- .. image:: img/ospi_sysfw.svg
- :alt: OSPI flash partition layout
- Kernel Image and DT are expected to be present in the /boot folder of UBIFS
- ospi.rootfs just like in SD card case. U-Boot looks for UBI volume named
- "rootfs" for rootfs.
- To boot kernel from OSPI, at the U-Boot prompt:
- .. code-block:: text
- => setenv boot ubi
- => boot
- UART:
- -----
- ROM supports booting from MCU_UART0 via X-Modem protocol. The entire UART-based
- boot process up to U-Boot (proper) prompt goes through different stages and uses
- different UART peripherals as follows:
- .. list-table:: ROM UART Boot Responsibilities
- :widths: 16 16 16 16
- :header-rows: 1
- * - Who
- - Loading What
- - Hardware Module
- - Protocol
- * - Boot ROM
- - tiboot3.bin
- - MCU_UART0
- - X-Modem(*)
- * - R5 SPL
- - sysfw.itb
- - MCU_UART0
- - Y-Modem(*)
- * - R5 SPL
- - tispl.bin
- - MAIN_UART0
- - Y-Modem
- * - A53 SPL
- - u-boot.img
- - MAIN_UART0
- - Y-Modem
- Note that in addition to X/Y-Modem related protocol timeouts the DMSC
- watchdog timeout of 3min (typ.) needs to be observed until System Firmware
- is fully loaded (from sysfw.itb) and started.
- Example bash script sequence for running on a Linux host PC feeding all boot
- artifacts needed to the device:
- .. code-block:: text
- MCU_DEV=/dev/ttyUSB1
- MAIN_DEV=/dev/ttyUSB0
- stty -F $MCU_DEV 115200 cs8 -cstopb -parenb
- stty -F $MAIN_DEV 115200 cs8 -cstopb -parenb
- sb --xmodem tiboot3.bin > $MCU_DEV < $MCU_DEV
- sb --ymodem sysfw.itb > $MCU_DEV < $MCU_DEV
- sb --ymodem tispl.bin > $MAIN_DEV < $MAIN_DEV
- sleep 1
- sb --xmodem u-boot.img > $MAIN_DEV < $MAIN_DEV
- Debugging U-Boot
- ----------------
- See :ref:`Common Debugging environment - OpenOCD<k3_rst_refer_openocd>`: for
- detailed setup information.
- .. warning::
- **OpenOCD support since**: v0.12.0
- If the default package version of OpenOCD in your development
- environment's distribution needs to be updated, it might be necessary to
- build OpenOCD from the source.
- .. include:: k3.rst
- :start-after: .. k3_rst_include_start_openocd_connect_XDS110
- :end-before: .. k3_rst_include_end_openocd_connect_XDS110
- To start OpenOCD and connect to the board
- .. code-block:: bash
- openocd -f board/ti_am654evm.cfg
|