3.1.1.1. General Information¶
3.1.1.1.1. Getting the U-Boot Source Code¶
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.
Note
Note about HSM Rearchitecture
After HSM rearchitecture in bootloader, loading of remote cores with firmware will be supported at A72 SPL stage only and not at R5 SPL stage. Early loading of remote core firmware in R5 SPL requires core reset functionality. As part of HSM rearchitecture, this functionality has moved into the DM service which requires SPL to re-implement device and clock control. This support is not present in Uboot R5 SPL due to memory constraints on the existing 64-bit TI devices.
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
$ git clone git://git.ti.com/security-development-tools/core-secdev-k3.git -b master
$ export TI_SECURE_DEV_PKG=`pwd`/core-secdev-k3
Setting 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:$PATH
Compiling R5 and ARM64 images
Use the following table to determine what defconfig to use to configure with:
Dependent Project location
- In case not use TI SDK and building U-Boot out of mainline, then k3-image-gen (For generating tiboot3.bin and sysfw.itb) project is located here
- Linux Firmware (for device specific ti-dm and ti-sysfw binaries) project is located here. Images are under ti-dm and ti-sysfw folders
Building SYSFW
- In case of building and generating sysfw.itb rather than downloading from prebuilt download location, below is the instructions on how to do it.
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.
Image Formats
- tiboot3.bin
+-----------------------+
| X.509 |
| Certificate |
| +-------------------+ |
| | | |
| | R5 | |
| | u-boot-spl.bin | |
| | | |
| +-------------------+ |
| | | |
| | FIT header | |
| | +---------------+ | |
| | | | | |
| | | DTB 1...N | | |
| | +---------------+ | |
| +-------------------+ |
+-----------------------+
- tispl.bin
+-----------------------+
| |
| FIT HEADER |
| +-------------------+ |
| | | |
| | ARM64 ATF | |
| +-------------------+ |
| | | |
| | ARM64 OPTEE | |
| +-------------------+ |
| | | |
| | ARM64 SPL | |
| +-------------------+ |
| | | |
| | SPL DTB 1...N | |
| +-------------------+ |
+-----------------------+
- sysfw.itb
+-----------------------+
| |
| FIT HEADER |
| +-------------------+ |
| | | |
| | sysfw.bin | |
| +-------------------+ |
| | | |
| | board config | |
| +-------------------+ |
| | | |
| | PM config | |
| +-------------------+ |
| | | |
| | RM config | |
| +-------------------+ |
| | | |
| | Secure config | |
| +-------------------+ |
+-----------------------+
3.1.1.1.3. 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 | R5 | ARM64 |
+------------------------------------------------------------------------+
| +--------+ | | |
| | Reset | | | |
| +--------+ | | |
| : | | |
| +--------+ | +-----------+ | |
| | *ROM* |----------|-->| Reset rls | | |
| +--------+ | +-----------+ | |
| | | | : | |
| | ROM | | : | |
| |services| | : | |
| | | | +-------------+ | |
| | | | | *R5 ROM* | | |
| | | | +-------------+ | |
| | |<---------|---|Load and auth| | |
| | | | | tiboot3.bin | | |
| | | | +-------------+ | |
| | | | : | |
| | | | : | |
| | | | : | |
| | | | +-------------+ | |
| | | | | *R5 SPL* | | |
| | | | +-------------+ | |
| | | | | Load | | |
| | | | | sysfw.itb | | |
| | Start | | +-------------+ | |
| | System |<---------|---| Start | | |
| |Firmware| | | SYSFW | | |
| +--------+ | +-------------+ | |
| : | | | | |
| +---------+ | | Load | | |
| | *SYSFW* | | | system | | |
| +---------+ | | Config data | | |
| | |<--------|---| | | |
| | | | +-------------+ | |
| | | | | | | |
| | | | | DDR | | |
| | | | | config | | |
| | | | +-------------+ | |
| | | | | | | |
| | |<--------|---| Start A53 | | |
| | | | | and Reset | | |
| | | | +-------------+ | |
| | | | | +-----------+ |
| | |---------|-----------------------|---->| Reset rls | |
| | | | | +-----------+ |
| | DMSC | | | : |
| |Services | | | +-----------+ |
| | |<--------|-----------------------|---->|*ATF/OPTEE*| |
| | | | | +-----------+ |
| | | | | : |
| | | | | +-----------+ |
| | |<--------|-----------------------|---->| *A53 SPL* | |
| | | | | +-----------+ |
| | | | | | Load | |
| | | | | | u-boot.img| |
| | | | | +-----------+ |
| | | | | : |
| | | | | +-----------+ |
| | |<--------|-----------------------|---->| *U-Boot* | |
| | | | | +-----------+ |
| | | | | | prompt | |
| | | | | +-----------+ |
| +---------+ | | |
| | | |
+------------------------------------------------------------------------+
Here acts as master and provides all the critical services. R5/ARM64 requests to get these services done as shown in the above diagram.
3.1.1.1.4. 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.5. 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.6. 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.7. SRAM memory Layout during R5 SPL bootloader stage¶
The SRAM memory layout explains the memory used for Bootloader’s operation.