3.1.1.1. General Information¶
3.1.1.1.1. Getting the U-Boot Source Code¶
The GIT repo URL, branch and commit id can be found in the U-Boot section of the release notes.
3.1.1.1.2. Build U-Boot¶
Note
The following commands are intended to be run from the root of the U-Boot tree unless otherwise specified. The root of the U-Boot tree is the top-level directory and can be identified by looking for the “MAINTAINERS” file.
Several prebuilt images are required from the TI Processor SDK for building U-Boot on K3 based platforms.
Go here to download and install the SDK.
TI-u-boot is included in the SDK in <path to tisdk>/board-support. Ensure that the u-boot version matches the U-Boot.
Getting Security Dev Tool
core-secdev-k3 is included in the SDK inside board-support directory.
$ export TI_SECURE_DEV_PKG=<path-to-board-support-directory>/core-secdev-k3Setting the tool chain path
We strongly recommend using the toolchain that came with the Linux Core release that corresponds to this U-Boot release. For e.g:
export PATH=$HOME/gcc-arm-9.2-2019.12-x86_64-arm-none-linux-gnueabihf/bin:$PATH export PATH=$HOME/gcc-arm-9.2-2019.12-x86_64-aarch64-none-linux-gnu/bin:$PATHCompiling R5 and ARM64 images
Use the following table to determine what defconfig to use to configure with:
Board SD Boot eMMC Boot UART boot OSPI boot AM64X EVM am64x_evm_r5_defconfig am64x_evm_a53_defconfig am64x_evm_r5_defconfig am64x_evm_a53_defconfig am64x_evm_r5_defconfig am64x_evm_a53_defconfig am64x_evm_r5_defconfig am64x_evm_a53_defconfig AM64X SK am64x_evm_r5_defconfig am64x_evm_a53_defconfig am64x_evm_r5_defconfig am64x_evm_a53_defconfig am64x_evm_r5_defconfig am64x_evm_a53_defconfig Note
Where to get the sources:
- ti-u-boot Branch: ti-u-boot-2021.01
- ti-k3-image-gen Branch: master
- ti-linux-firmware Branch: ti-linux-firmware
- arm-trusted-firmware Commit: 2fcd408bb3a6756767a43c073c597cef06e7f2d5
- optee-os Commit: 3bc3809afe372ca7e8216fc5d7a64e965bb4ad70
Notice: arm-trusted-firmware and optee-os are now sourced from upstream.
$ export UBOOT_DIR=<path-to-ti-u-boot> $ export K3IG_DIR=<path-to-k3-image-gen> $ export SYSFW_DIR=<path-to-ti-linux-firmware>/ti-sysfw $ export TFA_DIR=<path-to-arm-trusted-firmware> $ export OPTEE_DIR=<path-to-ti-optee-os>Note
The instructions below assume all binaries are built manually. For instructions to build bl31.bin go to: OP-TEE. For instructions to build bl32.bin/tee-pager_v2.bin go to: ARM Trusted Firmware-A. To use existing images, go to <path-to-tisdk>/board-support/prebuilt-images to get the pre-build binares that come in the pre-built sdk.
on HS-FS
R5 To build u-boot-spl.bin for tiboot3.bin. Saved in $UBOOT_DIR/out/r5. $ make ARCH=arm CROSS_COMPILE=arm-none-linux-gnueabihf- am64x_evm_r5_defconfig O=$UBOOT_DIR/out/r5 $ make ARCH=arm CROSS_COMPILE=arm-none-linux-gnueabihf- O=$UBOOT_DIR/out/r5 To build tiboot3-am64x_sr2-hs-fs-evm.bin. Saved in $K3IG_DIR. Requires u-boot-spl.bin, TISCI HS-FS FW. $ cd $K3IG_DIR $ make CROSS_COMPILE=arm-none-linux-gnueabihf- SOC=am64x_sr2 SOC_TYPE=hs-fs SBL=$UBOOT_DIR/out/r5/spl/u-boot-spl.bin SYSFW_DIR=$SYSFW_DIR Sign OPTEE and ATF binaries $ $TI_SECURE_DEV_PKG/scripts/secure-binary-image.sh bl31.bin bl31.bin.signed $ $TI_SECURE_DEV_PKG/scripts/secure-binary-image.sh bl32.bin bl32.bin.signed A53 To build tispl.bin and u-boot.img. Saved in $UBOOT_DIR/out/a53. Requires bl31.bin.signed and bl32.bin.signed. $ make ARCH=arm CROSS_COMPILE=aarch64-none-linux-gnu- am64x_evm_a53_defconfig O=$UBOOT_DIR/out/a53 $ make ARCH=arm CROSS_COMPILE=aarch64-none-linux-gnu- ATF=$TFA_DIR/build/k3/lite/release/bl31.bin.signed TEE=$OPTEE_DIR/out/arm-plat-k3/core/bl32.bin.signed O=$UBOOT_DIR/out/a53on GP
R5 To build u-boot-spl.bin for tiboot3.bin. Saved in $UBOOT_DIR/out/r5. $ make ARCH=arm CROSS_COMPILE=arm-none-linux-gnueabihf- am64x_evm_r5_defconfig O=$UBOOT_DIR/out/r5 $ make ARCH=arm CROSS_COMPILE=arm-none-linux-gnueabihf- O=$UBOOT_DIR/out/r5 To build tiboot3-am64x-gp-evm.bin. Saved in $K3IG_DIR. Requires u-boot-spl.bin and ti-sci-firmware-am64x-gp.bin. $ cd $K3IG_DIR $ make CROSS_COMPILE=arm-none-linux-gnueabihf- SOC=am64x SOC_TYPE=gp SBL=$UBOOT_DIR/out/r5/spl/u-boot-spl.bin SYSFW_DIR=$SYSFW_DIR A53 To build tispl.bin_unsigned and u-boot.img_unsigned. Saved in $UBOOT_DIR/out/a53. Requires bl31.bin and tee-pager_v2.bin. $ make ARCH=arm CROSS_COMPILE=aarch64-none-linux-gnu- am64x_evm_a53_defconfig O=$UBOOT_DIR/out/a53 $ make CROSS_COMPILE=aarch64-none-linux-gnu- ATF=$TFA_DIR/build/k3/lite/release/bl31.bin TEE=$OPTEE_DIR/out/arm-plat-k3/core/tee-pager_v2.bin O=$UBOOT_DIR/out/a53on HS
R5 To build u-boot-spl.bin for tiboot3.bin. Saved in $UBOOT_DIR/out/r5. $ make ARCH=arm CROSS_COMPILE=arm-none-linux-gnueabihf- am64x_evm_r5_defconfig O=$UBOOT_DIR/out/r5 $ make ARCH=arm CROSS_COMPILE=arm-none-linux-gnueabihf- O=$UBOOT_DIR/out/r5 To build tiboot3-am64x_sr2-hs-evm.bin. Saved in $K3IG_DIR. Requires u-boot-spl.bin, TISCI HS-SE FW $ cd $K3IG_DIR $ make CROSS_COMPILE=arm-none-linux-gnueabihf- SOC=am64x_sr2 SOC_TYPE=hs SBL=$UBOOT_DIR/out/r5/spl/u-boot-spl.bin SYSFW_DIR=$SYSFW_DIR Sign OPTEE and ATF binaries $ $TI_SECURE_DEV_PKG/scripts/secure-binary-image.sh bl31.bin bl31.bin.signed $ $TI_SECURE_DEV_PKG/scripts/secure-binary-image.sh bl32.bin bl32.bin.signed A53 To build tispl.bin and u-boot.img. Saved in $UBOOT_DIR/out/a53. Requires bl31.bin.signed and bl32.bin.signed. $ make ARCH=arm CROSS_COMPILE=aarch64-none-linux-gnu- am64x_evm_a53_defconfig O=$UBOOT_DIR/out/a53 $ make ARCH=arm CROSS_COMPILE=aarch64-none-linux-gnu- ATF=$TFA_DIR/build/k3/lite/release/bl31.bin.signed TEE=$OPTEE_DIR/out/arm-plat-k3/core/bl32.bin.signed O=$UBOOT_DIR/out/a53
Target Images
Copy the below images to the boot partition of an SD card and boot. Instructions to format the SD card can be found here.
- tiboot3.bin from <path to K3-image-gen> (This is combined image of tiboot3.bin and sysfw.itb)
- tispl.bin, u-boot.img from <output directory>/a53
3.1.1.1.3. Image Formats¶
tiboot3.bin:
+-----------------------+ | X.509 | | Certificate | | +-------------------+ | | | | | | | R5 | | | | u-boot-spl.bin | | | | | | | +-------------------+ | | | | | | | FIT header | | | | +---------------+ | | | | | | | | | | | DTB 1...N | | | | | +---------------+ | | | +-------------------+ | | | | | | | FIT HEADER | | | | +---------------+ | | | | | | | | | | | sysfw.bin | | | | | +---------------+ | | | | | | | | | | | board config | | | | | +---------------+ | | | | | | | | | | | PM config | | | | | +---------------+ | | | | | | | | | | | RM config | | | | | +---------------+ | | | | | | | | | | | Secure config | | | | | +---------------+ | | | +-------------------+ | +-----------------------+tispl.bin
+-----------------------+ | | | FIT HEADER | | +-------------------+ | | | | | | | A53 ATF | | | +-------------------+ | | | | | | | A53 OPTEE | | | +-------------------+ | | | | | | | A53 SPL | | | +-------------------+ | | | | | | | SPL DTB 1...N | | | +-------------------+ | +-----------------------+
3.1.1.1.4. Boot Flow¶
On K3 architecture based devices, ROM supports boot only via MCU(R5). This means that bootloader has to run on R5 core. In order to meet this constraint, keeping safety in picture and to have faster boot time, the software boot architecture is designed as below:
+------------------------------------------------------------------------+-----------------------+
| DMSC | MAIN R50 | A53 | MAIN R51 |
+------------------------------------------------------------------------+-----------------------+
| +--------+ | | | |
| | Reset | | | | |
| +--------+ | | | |
| : | | | |
| +--------+ | +-----------+ | | |
| | *ROM* |----------|-->| Reset rls | | | |
| +--------+ | +-----------+ | | |
| | | | : | | |
| | ROM | | : | | |
| |services| | : | | |
| | | | +-------------+ | | |
| | | | | *R5 ROM* | | | |
| | | | +-------------+ | | |
| | |<---------|---|Load and auth| | | |
| | | | | tiboot3.bin | | | |
| | Start | | +-------------+ | | |
| | SYSFW |<---------|---| Start | | | |
| | | | | SYSFW | | | |
| +--------+ | +-------------+ | | |
| : | | | | | |
| +---------+ | | Load | | | |
| | *SYSFW* | | | system | | | |
| +---------+ | | Config data | | | |
| | |<--------|---| | | | |
| | | | +-------------+ | | |
| | | | : | | |
| | | | : | | |
| | | | : | | |
| | | | +-------------+ | | |
| | | | | *R5 SPL* | | | |
| | | | +-------------+ | | |
| | | | | DDR | | | |
| | | | | config | | | |
| | | | +-------------+ | | |
| | | | | Load | | | |
| | | | | tispl.bin | | | |
| | | | +-------------+ | | |
| | |<--------|---| Start A53 | | | |
| | | | +-------------+ | | |
| | | | | +-----------+ | |
| | |---------|-----------------------|---->| Reset rls | | |
| | | | | +-----------+ | |
| | SYSFW | | | : | |
| |Services | | | +-----------+ | |
| | |<--------|-----------------------|---->|*ATF/OPTEE*| | |
| | | | | +-----------+ | |
| | | | | : | |
| | | | | +-----------+ | |
| | |<--------|-----------------------|---->| *A53 SPL* | | |
| | | | | +-----------+ | |
| | | | | | Load | | |
| | | | | | u-boot.img| | |
| | | | | +-----------+ | |
| | | | | : | |
| | | | | +-----------+ | |
| | |<--------|-----------------------|---->| *U-Boot* | | |
| | | | | +-----------+ | |
| | | | | | prompt | | |
| | | | | +-----------+ | |
| | | | | | Load R5 | | |
| | | | | | Firmware | | |
| | | | | +-----------+ | |
| | |<--------|-----------------------|-----| Start R5 | | +-----------+ |
| | |---------|-----------------------|-----+-----------+-----|----->| R5 starts | |
| | | | | | +-----------+ |
| | | | | | |
| +---------+ | | | |
| | | | |
+------------------------------------------------------------------------+-----------------------+
Here DMSC acts as master and provides all the critical services. R5/ARM64 requests DMSC to get these services done as shown in the above diagram.
3.1.1.1.5. U-Boot Environment¶
Please note that on many boards we modify the environment during system start for a variety of variables such as board_name and if unset, ethaddr. When we restore defaults some variables will become unset, and this can lead to other things not working such as findfdt that rely on these run-time set variables.
Restoring defaults
It is possible to reset the set of U-Boot environment variables to their defaults and if desired, save them to where the environment is stored, if applicable. It is also required to restore the default setting when u-boot version changes from an upgrade or downgrade. To do so, issue the following commands:
U-Boot # env default -f -a
U-Boot # saveenv
Networking Environment
When using a USB-Ethernet dongle a valid MAC address must be set in the environment. To create a valid address please read **this page**. Then issue the following command:
U-Boot # setenv usbethaddr value:from:link:above
You can use the printenv command to see if usbethaddr is already set.
Then start the USB subsystem:
U-Boot # usb start
The default behavior of U-Boot is to utilize all information that a DHCP server passes to us when the user issues the dhcp command. This will include the dhcp parameter next-server which indicates where to fetch files from via TFTP. There may be times however where the dhcp server on your network provides incorrect information and you are unable to modify the server. In this case the following steps can be helpful:
U-Boot # setenv autoload no
U-Boot # dhcp
U-Boot # setenv serverip correct.server.ip
U-Boot # tftp
Another alternative is to utilize the full syntax of the tftp command:
U-Boot # setenv autoload no
U-Boot # dhcp
U-Boot # tftp ${loadaddr} server.ip:fileName
3.1.1.1.6. Available RAM for image download¶
To know the amount of RAM available for downloading images or for other
usage, use bdinfo command.
=> bdinfo
arch_number = 0x00000000
boot_params = 0x80000100
DRAM bank = 0x00000000
-> start = 0x80000000
-> size = 0x7F000000
baudrate = 115200 bps
TLB addr = 0xFEFF0000
relocaddr = 0xFEF30000
reloc off = 0x7E730000
irq_sp = 0xFCEF8880
sp start = 0xFCEF8870
Early malloc usage: 890 / 2000
After booting, U-Boot relocates itself (along with its various reserved
RAM areas) and places itself at end of available RAM (starting at
relocaddr in bdinfo output above). Only the stack is located
just before that area. The address of top of the stack is in
sp start in bdinfo output and it grows downwards. Users should
reserve at least about 1MB for stack, so in the example output above,
RAM in the range of [0x80000000, 0xFCE00000] is safely available for
use.
3.1.1.1.7. Device Trees¶
A note about device trees. Now all supported boards are required to use a device tree to boot. To facilitate this in supported platforms, a command in U-Boot environment findfdt is available that will set the fdtfile variable to the name of the device tree to use, as found with the kernel sources. In the Keystone-2 family devices (K2H/K/E/L/G), it is specified by name_fdt variable for each platform. The device tree is expected to be loaded from the same media as the kernel, and from the same relative path.
3.1.1.1.8. SRAM memory Layout during R5 SPL bootloader stage¶
The SRAM memory layout explains the memory used for Bootloader’s operation.
- In SDK 08.00 release, USB DFU boot mode support has been added in AM64. For USB DFU boot mode there is a limitation on the load address of boot images to be less than 0x70001000. In order to overcome this limitation, the R5 SPL load address has been moved to 0x70000000. Given below is the SRAM memory layout in SDK 08.00 release, during R5 SPL bootloader stage.
┌──────────────────────────────────────┐0x70000000 │ │ │ │ │ │ │ SPL IMAGE (Max size 1.5 MB) │ │ │ │ │ │ │ ├──────────────────────────────────────┤0x7017FFFF │ │ │ SPL STACK │ │ │ ├──────────────────────────────────────┤0x70192727 │ GLOBAL DATA(216 B) │ ├──────────────────────────────────────┤0x701927FF │ │ │ INITIAL HEAP (32 KB) │ │ │ ├──────────────────────────────────────┤0x7019A7FF │ │ │ BSS (20 KB) │ ├──────────────────────────────────────┤0x7019F7FF │ EEPROM DATA (2 KB) │ ├──────────────────────────────────────┤0x7019FFFF │ │ │ │ │ TF-A (123 KB) │ │ │ │ │ ├──────────────────────────────────────┤0x701BEBFB │ BOOT PARAMETER INDEX TABLE (5124 B)│ ├──────────────────────────────────────┤0x701BFFFF │ │ │ UNALLOCATED AREA(128 KB) │ │ │ ├──────────────────────────────────────┤0x701DFFFF │ │ │ DMSC CODE AREA (128 KB) │ │ │ └──────────────────────────────────────┘0x701FFFFF
- In SDK 08.01 release, TF-A will be moved to 0x701c0000 and 128 KB will be reserved for it. Given below is the memory layout after making this change.
┌──────────────────────────────────────┐0x70000000 │ │ │ │ │ │ │ SPL IMAGE (Max size 1.5 MB) │ │ │ │ │ │ │ ├──────────────────────────────────────┤0x7017FFFF │ │ │ SPL STACK │ │ │ ├──────────────────────────────────────┤0x70192727 │ GLOBAL DATA(216 B) │ ├──────────────────────────────────────┤0x701927FF │ │ │ INITIAL HEAP (32 KB) │ │ │ ├──────────────────────────────────────┤0x7019A7FF │ │ │ BSS (20 KB) │ ├──────────────────────────────────────┤0x7019F7FF │ EEPROM DATA (2 KB) │ ├──────────────────────────────────────┤0x7019FFFF │ │ │ │ │ UNALLOCATED AREA (123 KB) │ │ │ │ │ ├──────────────────────────────────────┤0x701BEBFB │ BOOT PARAMETER INDEX TABLE (5124 B)│ ├──────────────────────────────────────┤0x701BFFFF │ │ │ TF-A (128 KB) │ │ │ ├──────────────────────────────────────┤0x701DFFFF │ │ │ DMSC CODE AREA (128 KB) │ │ │ └──────────────────────────────────────┘0x701FFFFF
- In the last 128 KB of memory used by DMSC during run time, initial 80 KB gets freed after a security handover happens. The last 48 KB still will be used by DMSC.
- For more details on Security handover see here .