Keystone II EVM Generation

Summary

This README has information on the U-Boot port for K2HK, K2E, and K2L EVM boards. Documentation for this board can be found at:

The K2HK board is based on Texas Instruments Keystone2 family of SoCs: K2H, K2K. More details on these SoCs are available at company websites:

K2K: https://www.ti.com/product/tci6638k2k K2H: https://www.ti.com/product/tci6638k2h

The K2E SoC details are available at

https://www.ti.com/lit/ds/symlink/66ak2e05.pdf

The K2L SoC details are available at

https://www.ti.com/lit/ds/symlink/tci6630k2l.pdf

The K2G SoC details are available at

https://www.ti.com/lit/ds/symlink/66ak2g02.pdf

Board Configuration

Some of the peripherals that are configured by U-Boot

DDR3

NAND

MSM SRAM

ETH Ports

UART

I2C

SPI

K2HK

2

512MB

6MB

4(2)

2

3

3

K2E

4

512MB

2MB

8(2)

2

3

3

K2L

2

512MB

2MB

4(2)

4

3

3

K2G

2

256MB

1MB

1

1

1

1

There are only 2 eth port installed on the boards.

There are separate PLLs to drive clocks to Tetris ARM and Peripherals. To bring up SMP Linux on this board, there is a boot monitor code that will be installed in MSMC SRAM. There is command available to install this image from U-Boot.

The port related files can be found at following folders:

  • keystone2 SoC related files: arch/arm/cpu/armv7/keystone/

  • EVMs board files: board/ti/k2s_evm/

Board configuration files:

  • include/configs/k2hk_evm.h

  • include/configs/k2e_evm.h

  • include/configs/k2l_evm.h

  • include/configs/k2g_evm.h

As U-Boot is migrating to Kconfig there is also board defconfig files

  • configs/k2e_evm_defconfig

  • configs/k2hk_evm_defconfig

  • configs/k2l_evm_defconfig

  • configs/k2g_evm_defconfig

Supported boot modes:

  • SPI NOR boot

  • AEMIF NAND boot (K2E, K2L and K2HK)

  • UART boot

  • MMC boot (Only on K2G)

Supported image formats:

  • u-boot.bin: for loading and running u-boot.bin through Texas Instruments Code Composer Studio (CCS) and for UART boot.

  • u-boot-spi.gph: gpimage for programming SPI NOR flash for SPI NOR boot

  • MLO: gpimage for programming NAND flash for NAND boot, MMC boot.

Build Instructions

Examples for k2hk, for k2e, k2l and k2g just replace k2hk prefix accordingly. Don’t forget to add CROSS_COMPILE.

To build u-boot.bin, u-boot-spi.gph, MLO:

make k2hk_evm_defconfig
make

Load and Run U-Boot on Keystone EVMs using CCS

Need Code Composer Studio (CCS) installed on a PC to load and run u-boot.bin on EVM? See instructions at below link for installing CCS on a Windows PC.

Use u-boot.bin from the build folder for loading and running U-Boot binary on EVM. Follow instructions at:

to configure SW1 dip switch to use “No Boot/JTAG DSP Little Endian Boot Mode” and Power ON the EVM. Follow instructions to connect serial port of EVM to PC and start TeraTerm or Hyper Terminal.

Start CCS on a Windows machine and Launch Target configuration as instructed at

The instructions provided in the above link uses a script for loading the U-Boot binary on the target EVM. Instead do the following:-

  1. Right click to “Texas Instruments XDS2xx USB Emulator_0/CortexA15_1 core (D is connected: Unknown)” at the debug window (This is created once Target configuration is launched) and select “Connect Target”.

  2. Once target connect is successful, choose Tools->Load Memory option from the top level menu. At the Load Memory window, choose the file u-boot.bin through “Browse” button and click “next >” button. In the next window, enter Start address as 0xc000000, choose Type-size “32 bits” and click “Finish” button.

  3. Click View -> Registers from the top level menu to view registers window.

  4. From Registers, window expand “Core Registers” to view PC. Edit PC value to be 0xc000000. From the “Run” top level menu, select “Free Run”

  5. The U-Boot prompt is shown at the Tera Term/ Hyper terminal console as below and type any key to stop autoboot as instructed.

U-Boot 2014.04-rc1-00201-gc215b5a (Mar 21 2014 - 12:47:59)

I2C:   ready
Detected SO-DIMM [SQR-SD3T-2G1333SED]
DRAM:  1.1 GiB
NAND:  512 MiB
Net:   K2HK_EMAC
Warning: K2HK_EMAC using MAC address from net device
, K2HK_EMAC1, K2HK_EMAC2, K2HK_EMAC3
Hit any key to stop autoboot:  0

SPI NOR Flash Programming Instructions

U-Boot image can be flashed to first 512KB of the NOR flash using following instructions:

  1. Start CCS and run U-Boot as described above.

  2. Suspend Target. Select Run -> Suspend from top level menu CortexA15_1 (Free Running)”

  3. Load u-boot-spi.gph binary from build folder on to DDR address 0x87000000 through CCS as described in step 2 of “Load and Run U-Boot on K2HK/K2E/K2L EVM using CCS”, but using address 0x87000000.

  4. Free Run the target as described earlier (step 4) to get U-Boot prompt

  5. At the U-Boot console type following to setup U-Boot environment variables.

setenv addr_uboot 0x87000000
setenv filesize <size in hex of u-boot-spi.gph rounded to hex 0x10000>
run burn_uboot_spi

Once U-Boot prompt is available, power off the EVM. Set the SW1 dip switch to “SPI Little Endian Boot mode” as per instruction at

  1. Power ON the EVM. The EVM now boots with U-Boot image on the NOR flash.

AEMIF NAND Flash programming instructions

U-Boot image can be flashed to first 1024KB of the NAND flash using following instructions:

  1. Start CCS and run U-Boot as described above.

  2. Suspend Target. Select Run -> Suspend from top level menu CortexA15_1 (Free Running)”

  3. Load MLO binary from build folder on to DDR address 0x87000000 through CCS as described in step 2 of “Load and Run U-Boot on K2HK EVM using CCS”, but using address 0x87000000.

  4. Free Run the target as described earlier (step 4) to get U-Boot prompt

  5. At the U-Boot console type following to setup U-Boot environment variables.

setenv filesize <size in hex of MLO rounded to hex 0x10000>
run burn_uboot_nand

Once U-Boot prompt is available, Power OFF the EVM. Set the SW1 dip switch to “ARM NAND Boot mode” as per instruction at

under Hardware Setup

  1. Power ON the EVM. The EVM now boots with U-Boot image on the NAND flash.

Load and Run U-Boot on keystone EVMs using UART download

Open BMC and regular UART terminals.

  1. On the regular UART port start xmodem transfer of the u-boot.bin

  2. Using BMC terminal set the ARM-UART bootmode and reboot the EVM

bootmode #4
reboot

  1. When xmodem is complete you should see the U-Boot starts on the UART port

Load and Run U-Boot on K2G EVMs using MMC

Open BMC and regular UART terminals.

  1. Set the SW3 dip switch to “ARM MMC Boot mode” as per instruction at

  2. Create SD card partitions as per steps given in Hardware Setup Guide.

  3. Copy MLO to Boot Partition.

  4. Insert SD card and Power on the EVM. The EVM now boots with U-Boot image from SD card.

Secure Boot

Secure TI devices require a boot image that is authenticated by ROM code to function. Without this, even JTAG remains locked and the device is essentially useless. In order to create a valid boot image for a secure device from TI, the initial public software image must be signed and combined with various headers, certificates, and other binary images.

Information on the details on the complete boot image format can be obtained from Texas Instruments. The tools used to generate boot images for secure devices are part of a secure development package (SECDEV) that can be downloaded from:

The secure development package is access controlled due to NDA and export control restrictions. Access must be requested and granted by TI before the package is viewable and downloadable. Contact TI, either online or by way of a local TI representative, to request access.

1. Booting of U-Boot SPL

When CONFIG_TI_SECURE_DEVICE is set, the U-Boot SPL build process requires the presence and use of these tools in order to create a viable boot image. The build process will look for the environment variable TI_SECURE_DEV_PKG, which should be the path of the installed SECDEV package. If the TI_SECURE_DEV_PKG variable is not defined or if it is defined but doesn’t point to a valid SECDEV package, a warning is issued during the build to indicate that a final secure bootable image was not created.

Within the SECDEV package exists an image creation script:

${TI_SECURE_DEV_PKG}/scripts/create-boot-image.sh

This is called as part of the SPL/u-boot build process. As the secure boot image formats and requirements differ between secure SOC from TI, the purpose of this script is to abstract these details as much as possible.

The script is basically the only required interface to the TI SECDEV package for creating a bootable SPL image for secure TI devices.

create-boot-image.sh \
             <IMAGE_FLAG> <INPUT_FILE> <OUTPUT_FILE> <SPL_LOAD_ADDR>

<IMAGE_FLAG> is currently ignored and reserved for future use.

<INPUT_FILE> is the full path and filename of the public world boot loader binary file (only u-boot.bin is currently supported on Keystone2 devices, u-boot-spl.bin is not currently supported).

<OUTPUT_FILE> is the full path and filename of the final secure image. The output binary images should be used in place of the standard non-secure binary images (see the platform-specific user’s guides and releases notes for how the non-secure images are typically used)

u-boot_HS_MLO

signed and encrypted boot image that can be used to boot from all media. Secure boot from SPI NOR flash is not currently supported.

2. Booting of Primary U-Boot (u-boot.img)

The SPL image is responsible for loading the next stage boot loader, which is the main u-boot image. For secure TI devices, the SPL will be authenticated, as described above, as part of the particular device’s ROM boot process. In order to continue the secure boot process, the authenticated SPL must authenticate the main u-boot image that it loads.

The configurations for secure TI platforms are written to make the boot process use the FIT image format for the u-boot.img (CONFIG_SPL_FRAMEWORK and CONFIG_SPL_LOAD_FIT). With these configurations the binary components that the SPL loads include a specific DTB image and u-boot image. These DTB image may be one of many available to the boot process. In order to secure these components so that they can be authenticated by the SPL as they are loaded from the FIT image, the build procedure for secure TI devices will secure these images before they are integrated into the FIT image. When those images are extracted from the FIT image at boot time, they are post-processed to verify that they are still secure. The outlined security-related SPL post-processing is enabled through the CONFIG_SPL_FIT_IMAGE_POST_PROCESS option which must be enabled for the secure boot scheme to work. In order to allow verifying proper operation of the secure boot chain in case of successful authentication messages like “Authentication passed” are output by the SPL to the console for each blob that got extracted from the FIT image.

The exact details of the how the images are secured is handled by the SECDEV package. Within the SECDEV package exists a script to process an input binary image:

${TI_SECURE_DEV_PKG}/scripts/secure-binary-image.sh

This is called as part of the u-boot build process. As the secure image formats and requirements can differ between the various secure SOCs from TI, this script in the SECDEV package abstracts these details. This script is essentially the only required interface to the TI SECDEV package for creating a u-boot.img image for secure TI devices.

The SPL/u-boot code contains calls to dedicated secure ROM functions to perform the validation on the secured images. The details of the interface to those functions is shown in the code. The summary is that they are accessed by invoking an ARM secure monitor call to the device’s secure ROM (fixed read-only-memory that is secure and only accessible when the ARM core is operating in the secure mode).

Invoking the secure-binary-image script for Secure Devices

secure-binary-image.sh <INPUT_FILE> <OUTPUT_FILE>

<INPUT_FILE> is the full path and filename of the input binary image

<OUTPUT_FILE> is the full path and filename of the output secure image.