mirror of
https://github.com/u-boot/u-boot.git
synced 2025-04-21 12:25:27 +00:00
doc: board: ti: Move documentation from README to .rst
Make the conversion for all existing TI documentation from README to .rst Signed-off-by: Neha Malcom Francis <n-francis@ti.com>
This commit is contained in:
Neha Malcom Francis
Heinrich Schuchardt
parent
129048a3b7
commit
7314ba2bf8
11 changed files with 959 additions and 718 deletions
|
|
@ -1,26 +0,0 @@
|
||||||
Summary
|
|
||||||
=======
|
|
||||||
|
|
||||||
This document covers various features of the 'dra7xx_evm' build and some
|
|
||||||
related uses.
|
|
||||||
|
|
||||||
eMMC boot partition use
|
|
||||||
=======================
|
|
||||||
|
|
||||||
It is possible, depending on SYSBOOT configuration to boot from the eMMC
|
|
||||||
boot partitions using (name depending on documentation referenced)
|
|
||||||
Alternative Boot operation mode or Boot Sequence Option 1/2. In this
|
|
||||||
example we load MLO and u-boot.img from the build into DDR and then use
|
|
||||||
'mmc bootbus' to set the required rate (see TRM) and 'mmc partconfig' to
|
|
||||||
set boot0 as the boot device.
|
|
||||||
U-Boot # setenv autoload no
|
|
||||||
U-Boot # usb start
|
|
||||||
U-Boot # dhcp
|
|
||||||
U-Boot # mmc dev 1 1
|
|
||||||
U-Boot # tftp ${loadaddr} dra7xx/MLO
|
|
||||||
U-Boot # mmc write ${loadaddr} 0 100
|
|
||||||
U-Boot # tftp ${loadaddr} dra7xx/u-boot.img
|
|
||||||
U-Boot # mmc write ${loadaddr} 300 400
|
|
||||||
U-Boot # mmc bootbus 1 2 0 2
|
|
||||||
U-Boot # mmc partconf 1 1 1 0
|
|
||||||
U-Boot # mmc rst-function 1 1
|
|
||||||
|
|
@ -1,194 +0,0 @@
|
||||||
U-Boot port for Texas Instruments Keystone II EVM boards
|
|
||||||
========================================================
|
|
||||||
|
|
||||||
Author: Murali Karicheri <m-karicheri2@ti.com>
|
|
||||||
|
|
||||||
This README has information on the U-Boot port for K2HK, K2E, and K2L EVM boards.
|
|
||||||
Documentation for this board can be found at
|
|
||||||
http://www.advantech.com/Support/TI-EVM/EVMK2HX_sd.aspx
|
|
||||||
https://www.einfochips.com/index.php/partnerships/texas-instruments/k2e-evm.html
|
|
||||||
https://www.einfochips.com/index.php/partnerships/texas-instruments/k2l-evm.html
|
|
||||||
|
|
||||||
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: http://www.ti.com/product/tci6638k2k
|
|
||||||
K2H: http://www.ti.com/product/tci6638k2h
|
|
||||||
|
|
||||||
The K2E SoC details are available at
|
|
||||||
http://www.ti.com/lit/ds/symlink/66ak2e05.pdf
|
|
||||||
|
|
||||||
The K2L SoC details are available at
|
|
||||||
http://www.ti.com/lit/ds/symlink/tci6630k2l.pdf
|
|
||||||
|
|
||||||
The K2G SoC details are available at
|
|
||||||
http://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 composure 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.
|
|
||||||
http://processors.wiki.ti.com/index.php/MCSDK_UG_Chapter_Getting_Started#
|
|
||||||
Installing_Code_Composer_Studio
|
|
||||||
Use u-boot.bin from the build folder for loading and running U-Boot binary
|
|
||||||
on EVM. Follow instructions at
|
|
||||||
K2HK http://processors.wiki.ti.com/index.php/EVMK2H_Hardware_Setup
|
|
||||||
K2E http://processors.wiki.ti.com/index.php/EVMK2E_Hardware_Setup
|
|
||||||
K2L http://processors.wiki.ti.com/index.php/TCIEVMK2L_Hardware_Setup
|
|
||||||
K2G http://processors.wiki.ti.com/index.php/66AK2G02_GP_EVM_Hardware_Setup
|
|
||||||
|
|
||||||
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 http://processors.wiki.ti.com/index.php/
|
|
||||||
MCSDK_UG_Chapter_Exploring#Loading_and_Running_U-Boot_on_EVM_through_CCS.
|
|
||||||
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
|
|
||||||
http://processors.wiki.ti.com/index.php/*_Hardware_Setup.
|
|
||||||
6. 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
|
|
||||||
http://processors.wiki.ti.com/index.php/*_Hardware_Setup.
|
|
||||||
6. 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
|
|
||||||
BMC> bootmode #4
|
|
||||||
MBC> reboot
|
|
||||||
3. 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
|
|
||||||
http://processors.wiki.ti.com/index.php/66AK2G02_GP_EVM_Hardware_Setup
|
|
||||||
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.
|
|
||||||
|
|
@ -1,226 +0,0 @@
|
||||||
README on how boot images are created for secure TI devices
|
|
||||||
|
|
||||||
CONFIG_TI_SECURE_DEVICE:
|
|
||||||
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:
|
|
||||||
|
|
||||||
http://www.ti.com/mysecuresoftware (login required)
|
|
||||||
|
|
||||||
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.
|
|
||||||
|
|
||||||
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.
|
|
||||||
|
|
||||||
Invoking the script for AM33xx Secure Devices
|
|
||||||
=============================================
|
|
||||||
|
|
||||||
create-boot-image.sh \
|
|
||||||
<IMAGE_FLAG> <INPUT_FILE> <OUTPUT_FILE> <SPL_LOAD_ADDR>
|
|
||||||
|
|
||||||
<IMAGE_FLAG> is a value that specifies the type of the image to
|
|
||||||
generate OR the action the image generation tool will take. Valid
|
|
||||||
values are:
|
|
||||||
SPI_X-LOADER - Generates an image for SPI flash (byte swapped)
|
|
||||||
X-LOADER - Generates an image for non-XIP flash
|
|
||||||
MLO - Generates an image for SD/MMC/eMMC media
|
|
||||||
2ND - Generates an image for USB, UART and Ethernet
|
|
||||||
XIP_X-LOADER - Generates a single stage u-boot for NOR/QSPI XiP
|
|
||||||
|
|
||||||
<INPUT_FILE> is the full path and filename of the public world boot
|
|
||||||
loaderbinary file (depending on the boot media, this is usually
|
|
||||||
either u-boot-spl.bin or u-boot.bin).
|
|
||||||
|
|
||||||
<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-spl_HS_SPI_X-LOADER - byte swapped boot image for SPI flash
|
|
||||||
u-boot-spl_HS_X-LOADER - boot image for NAND or SD/MMC/eMMC rawmode
|
|
||||||
u-boot-spl_HS_MLO - boot image for SD/MMC/eMMC media
|
|
||||||
u-boot-spl_HS_2ND - boot image for USB, UART and Ethernet
|
|
||||||
u-boot_HS_XIP_X-LOADER - boot image for NOR or QSPI Xip flash
|
|
||||||
|
|
||||||
<SPL_LOAD_ADDR> is the address at which SOC ROM should load the
|
|
||||||
<INPUT_FILE>
|
|
||||||
|
|
||||||
Invoking the script for AM43xx Secure Devices
|
|
||||||
=============================================
|
|
||||||
|
|
||||||
create-boot-image.sh \
|
|
||||||
<IMAGE_FLAG> <INPUT_FILE> <OUTPUT_FILE> <SPL_LOAD_ADDR>
|
|
||||||
|
|
||||||
<IMAGE_FLAG> is a value that specifies the type of the image to
|
|
||||||
generate OR the action the image generation tool will take. Valid
|
|
||||||
values are:
|
|
||||||
SPI_X-LOADER - Generates an image for SPI flash (byte
|
|
||||||
swapped)
|
|
||||||
XIP_X-LOADER - Generates a single stage u-boot for
|
|
||||||
NOR/QSPI XiP
|
|
||||||
ISSW - Generates an image for all other boot modes
|
|
||||||
|
|
||||||
<INPUT_FILE> is the full path and filename of the public world boot
|
|
||||||
loaderbinary file (depending on the boot media, this is usually
|
|
||||||
either u-boot-spl.bin or u-boot.bin).
|
|
||||||
|
|
||||||
<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-spl_HS_SPI_X-LOADER - byte swapped boot image for SPI flash
|
|
||||||
u-boot_HS_XIP_X-LOADER - boot image for NOR or QSPI flash
|
|
||||||
u-boot-spl_HS_ISSW - boot image for all other boot media
|
|
||||||
|
|
||||||
<SPL_LOAD_ADDR> is the address at which SOC ROM should load the
|
|
||||||
<INPUT_FILE>
|
|
||||||
|
|
||||||
Invoking the script for DRA7xx/AM57xx Secure Devices
|
|
||||||
====================================================
|
|
||||||
|
|
||||||
create-boot-image.sh \
|
|
||||||
<IMAGE_TYPE> <INPUT_FILE> <OUTPUT_FILE> <SPL_LOAD_ADDR>
|
|
||||||
|
|
||||||
<IMAGE_TYPE> is a value that specifies the type of the image to
|
|
||||||
generate OR the action the image generation tool will take. Valid
|
|
||||||
values are:
|
|
||||||
X-LOADER - Generates an image for NOR or QSPI boot modes
|
|
||||||
MLO - Generates an image for SD/MMC/eMMC boot modes
|
|
||||||
ULO - Generates an image for USB/UART peripheral boot modes
|
|
||||||
|
|
||||||
<INPUT_FILE> is the full path and filename of the public world boot
|
|
||||||
loader binary file (for this platform, this is always u-boot-spl.bin).
|
|
||||||
|
|
||||||
<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-spl_HS_MLO - boot image for SD/MMC/eMMC. This image is
|
|
||||||
copied to a file named MLO, which is the name that
|
|
||||||
the device ROM bootloader requires for loading from
|
|
||||||
the FAT partition of an SD card (same as on
|
|
||||||
non-secure devices)
|
|
||||||
u-boot-spl_HS_ULO - boot image for USB/UART peripheral boot modes
|
|
||||||
u-boot-spl_HS_X-LOADER - boot image for all other flash memories
|
|
||||||
including QSPI and NOR flash
|
|
||||||
|
|
||||||
<SPL_LOAD_ADDR> is the address at which SOC ROM should load the
|
|
||||||
<INPUT_FILE>
|
|
||||||
|
|
||||||
Invoking the script for Keystone2 Secure Devices
|
|
||||||
================================================
|
|
||||||
|
|
||||||
create-boot-image.sh \
|
|
||||||
<UNUSED> <INPUT_FILE> <OUTPUT_FILE> <UNUSED>
|
|
||||||
|
|
||||||
<UNUSED> 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.
|
|
||||||
|
|
||||||
Invoking the script for K3 Secure Devices
|
|
||||||
=========================================
|
|
||||||
|
|
||||||
The signing steps required to produce a bootable SPL image on secure
|
|
||||||
K3 TI devices are the same as those performed on non-secure devices.
|
|
||||||
The only difference is the key is not checked on non-secure devices so
|
|
||||||
a dummy key is used when building U-Boot for those devices. For secure
|
|
||||||
K3 TI devices simply use the real hardware key for your device. This
|
|
||||||
real key can be set with the Kconfig option "K3_KEY". The environment
|
|
||||||
variable TI_SECURE_DEV_PKG is also searched for real keys when the
|
|
||||||
build targets secure devices.
|
|
||||||
|
|
||||||
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.
|
|
||||||
|
|
@ -1,76 +0,0 @@
|
||||||
Testing details-
|
|
||||||
----------------
|
|
||||||
|
|
||||||
This doc simply illustrated the testing details of qspi flash
|
|
||||||
driver with Macronix M25L51235 flash device.
|
|
||||||
|
|
||||||
The test includes
|
|
||||||
- probing the flash device
|
|
||||||
- erasing the flash device
|
|
||||||
- Writing to flash
|
|
||||||
- Reading the contents of the flash.
|
|
||||||
|
|
||||||
Test Log
|
|
||||||
--------
|
|
||||||
|
|
||||||
Hit any key to stop autoboot: 0
|
|
||||||
U-Boot# sf probe 0
|
|
||||||
SF: Detected MX25L51235F with page size 256 Bytes, erase size 64 KiB, total 64 MiB, mapped at 30000000
|
|
||||||
U-Boot# sf erase 0 0x80000
|
|
||||||
SF: 524288 bytes @ 0x0 Erased: OK
|
|
||||||
U-Boot# mw 81000000 0xdededede 0x40000
|
|
||||||
U-Boot# sf write 81000000 0 0x40000
|
|
||||||
SF: 262144 bytes @ 0x0 Written: OK
|
|
||||||
U-Boot# sf read 82000000 0 0x40000
|
|
||||||
SF: 262144 bytes @ 0x0 Read: OK
|
|
||||||
U-Boot# md 0x82000000
|
|
||||||
82000000: dededede dededede dededede dededede ................
|
|
||||||
82000010: dededede dededede dededede dededede ................
|
|
||||||
82000020: dededede dededede dededede dededede ................
|
|
||||||
82000030: dededede dededede dededede dededede ................
|
|
||||||
82000040: dededede dededede dededede dededede ................
|
|
||||||
82000050: dededede dededede dededede dededede ................
|
|
||||||
82000060: dededede dededede dededede dededede ................
|
|
||||||
82000070: dededede dededede dededede dededede ................
|
|
||||||
82000080: dededede dededede dededede dededede ................
|
|
||||||
82000090: dededede dededede dededede dededede ................
|
|
||||||
820000a0: dededede dededede dededede dededede ................
|
|
||||||
820000b0: dededede dededede dededede dededede ................
|
|
||||||
820000c0: dededede dededede dededede dededede ................
|
|
||||||
820000d0: dededede dededede dededede dededede ................
|
|
||||||
820000e0: dededede dededede dededede dededede ................
|
|
||||||
820000f0: dededede dededede dededede dededede ................
|
|
||||||
U-Boot# md 0x82010000
|
|
||||||
82010000: dededede dededede dededede dededede ................
|
|
||||||
82010010: dededede dededede dededede dededede ................
|
|
||||||
82010020: dededede dededede dededede dededede ................
|
|
||||||
82010030: dededede dededede dededede dededede ................
|
|
||||||
82010040: dededede dededede dededede dededede ................
|
|
||||||
82010050: dededede dededede dededede dededede ................
|
|
||||||
82010060: dededede dededede dededede dededede ................
|
|
||||||
82010070: dededede dededede dededede dededede ................
|
|
||||||
82010080: dededede dededede dededede dededede ................
|
|
||||||
82010090: dededede dededede dededede dededede ................
|
|
||||||
820100a0: dededede dededede dededede dededede ................
|
|
||||||
820100b0: dededede dededede dededede dededede ................
|
|
||||||
820100c0: dededede dededede dededede dededede ................
|
|
||||||
820100d0: dededede dededede dededede dededede ................
|
|
||||||
820100e0: dededede dededede dededede dededede ................
|
|
||||||
820100f0: dededede dededede dededede dededede ................
|
|
||||||
U-Boot# md 0x82030000
|
|
||||||
82030000: dededede dededede dededede dededede ................
|
|
||||||
82030010: dededede dededede dededede dededede ................
|
|
||||||
82030020: dededede dededede dededede dededede ................
|
|
||||||
82030030: dededede dededede dededede dededede ................
|
|
||||||
82030040: dededede dededede dededede dededede ................
|
|
||||||
82030050: dededede dededede dededede dededede ................
|
|
||||||
82030060: dededede dededede dededede dededede ................
|
|
||||||
82030070: dededede dededede dededede dededede ................
|
|
||||||
82030080: dededede dededede dededede dededede ................
|
|
||||||
82030090: dededede dededede dededede dededede ................
|
|
||||||
820300a0: dededede dededede dededede dededede ................
|
|
||||||
820300b0: dededede dededede dededede dededede ................
|
|
||||||
820300c0: dededede dededede dededede dededede ................
|
|
||||||
820300d0: dededede dededede dededede dededede ................
|
|
||||||
820300e0: dededede dededede dededede dededede ................
|
|
||||||
820300f0: dededede dededede dededede dededede ................
|
|
||||||
|
|
@ -1,47 +0,0 @@
|
||||||
-------------------------------------------------
|
|
||||||
Simple steps used to test the QSPI at U-Boot
|
|
||||||
-------------------------------------------------
|
|
||||||
|
|
||||||
For #1, build the patched U-Boot and load MLO/u-boot.img
|
|
||||||
|
|
||||||
----------------------------------
|
|
||||||
Boot from another medium like MMC
|
|
||||||
----------------------------------
|
|
||||||
|
|
||||||
U-Boot# mmc dev 0
|
|
||||||
mmc0 is current device
|
|
||||||
U-Boot# fatload mmc 0 0x82000000 MLO
|
|
||||||
reading MLO
|
|
||||||
55872 bytes read in 8 ms (6.7 MiB/s)
|
|
||||||
U-Boot# fatload mmc 0 0x83000000 u-boot.img
|
|
||||||
reading u-boot.img
|
|
||||||
248600 bytes read in 19 ms (12.5 MiB/s)
|
|
||||||
|
|
||||||
--------------------------------------------------
|
|
||||||
Commands to erase/write u-boot/mlo to flash device
|
|
||||||
--------------------------------------------------
|
|
||||||
U-Boot# sf probe 0
|
|
||||||
SF: Detected S25FL256S_64K with page size 256 Bytes, erase size 64 KiB, total 32 MiB, mapped at 5c000000
|
|
||||||
U-Boot# sf erase 0 0x10000
|
|
||||||
SF: 65536 bytes @ 0x0 Erased: OK
|
|
||||||
U-Boot# sf erase 0x20000 0x10000
|
|
||||||
SF: 65536 bytes @ 0x20000 Erased: OK
|
|
||||||
U-Boot# sf erase 0x30000 0x10000
|
|
||||||
SF: 65536 bytes @ 0x30000 Erased: OK
|
|
||||||
U-Boot# sf erase 0x40000 0x10000
|
|
||||||
SF: 65536 bytes @ 0x40000 Erased: OK
|
|
||||||
U-Boot# sf erase 0x50000 0x10000
|
|
||||||
SF: 65536 bytes @ 0x50000 Erased: OK
|
|
||||||
U-Boot# sf erase 0x60000 0x10000
|
|
||||||
SF: 65536 bytes @ 0x60000 Erased: OK
|
|
||||||
U-Boot# sf write 82000000 0 0x10000
|
|
||||||
SF: 65536 bytes @ 0x0 Written: OK
|
|
||||||
U-Boot# sf write 83000000 0x20000 0x60000
|
|
||||||
SF: 393216 bytes @ 0x20000 Written: OK
|
|
||||||
|
|
||||||
For #2, set sysboot to QSPI-1 boot mode(SYSBOOT[5:0] = 100110) and power
|
|
||||||
on. ROM should find the GP header at offset 0 and load/execute SPL. SPL
|
|
||||||
then detects that ROM was in QSPI-1 mode (boot code 10) and attempts to
|
|
||||||
find a U-Boot image header at offset 0x20000 (set in the config file)
|
|
||||||
and proceeds to load that image using the U-Boot image payload offset/size
|
|
||||||
from the header. It will then start U-Boot.
|
|
||||||
|
|
@ -1,47 +0,0 @@
|
||||||
QSPI U-Boot support
|
|
||||||
------------------
|
|
||||||
|
|
||||||
Host processor is connected to serial flash device via qpsi
|
|
||||||
interface. QSPI is a kind of spi module that allows single,
|
|
||||||
dual and quad read access to external spi devices. The module
|
|
||||||
has a memory mapped interface which provide direct interface
|
|
||||||
for accessing data form external spi devices.
|
|
||||||
|
|
||||||
The one QSPI in the device is primarily intended for fast booting
|
|
||||||
from Quad SPI flash devices.
|
|
||||||
|
|
||||||
Usecase
|
|
||||||
-------
|
|
||||||
|
|
||||||
MLO/u-boot.img will be flashed from SD/MMC to the flash device
|
|
||||||
using serial flash erase and write commands. Then, switch settings
|
|
||||||
will be changed to qspi boot. Then, the ROM code will read MLO
|
|
||||||
from the predefined location in the flash, where it was flashed and
|
|
||||||
execute it after storing it in SDRAM. Then, the MLO will read
|
|
||||||
u-boot.img from flash and execute it from SDRAM.
|
|
||||||
|
|
||||||
SPI mode
|
|
||||||
-------
|
|
||||||
SPI mode uses mtd spi framework for transfer and reception of data.
|
|
||||||
Can be used in:
|
|
||||||
1. Normal mode: use single pin for transfers
|
|
||||||
2. Dual Mode: use two pins for transfers.
|
|
||||||
3. Quad mode: use four pin for transfer
|
|
||||||
|
|
||||||
Memory mapped read mode
|
|
||||||
-----------------------
|
|
||||||
In this, SPI controller is configured using configuration port and then
|
|
||||||
controller is switched to memory mapped port for data read.
|
|
||||||
|
|
||||||
Driver
|
|
||||||
------
|
|
||||||
drivers/qspi/ti_qspi.c
|
|
||||||
- Newly created file which is responsible for configuring the
|
|
||||||
qspi controller and also for providing the low level api which
|
|
||||||
is responsible for transferring the datas from host controller
|
|
||||||
to flash device and vice versa.
|
|
||||||
|
|
||||||
Testing
|
|
||||||
-------
|
|
||||||
A seperated file named README.dra_qspi_test has been created which gives all the
|
|
||||||
details about the commands required to test qspi at U-Boot level.
|
|
||||||
|
|
@ -43,6 +43,180 @@ to look at both `include/configs/am335x_evm.h`,
|
||||||
`include/configs/ti_am335x_common.h` and `include/configs/am335x_evm.h` as the
|
`include/configs/ti_am335x_common.h` and `include/configs/am335x_evm.h` as the
|
||||||
migration to Kconfig is not yet complete.
|
migration to Kconfig is not yet complete.
|
||||||
|
|
||||||
|
Secure Boot
|
||||||
|
-----------
|
||||||
|
|
||||||
|
.. secure_boot_include_start_config_ti_secure_device
|
||||||
|
|
||||||
|
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:
|
||||||
|
|
||||||
|
http://www.ti.com/mysecuresoftware (login required)
|
||||||
|
|
||||||
|
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.
|
||||||
|
|
||||||
|
.. secure_boot_include_end_config_ti_secure_device
|
||||||
|
|
||||||
|
.. secure_boot_include_start_spl_boot
|
||||||
|
|
||||||
|
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:
|
||||||
|
|
||||||
|
.. prompt:: bash
|
||||||
|
:prompts: $
|
||||||
|
|
||||||
|
${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.
|
||||||
|
|
||||||
|
.. prompt:: bash
|
||||||
|
:prompts: $
|
||||||
|
|
||||||
|
create-boot-image.sh \
|
||||||
|
<IMAGE_FLAG> <INPUT_FILE> <OUTPUT_FILE> <SPL_LOAD_ADDR>
|
||||||
|
|
||||||
|
.. secure_boot_include_end_spl_boot
|
||||||
|
|
||||||
|
<IMAGE_FLAG> is a value that specifies the type of the image to
|
||||||
|
generate OR the action the image generation tool will take. Valid
|
||||||
|
values are:
|
||||||
|
|
||||||
|
.. list-table::
|
||||||
|
:widths: 25 25
|
||||||
|
:header-rows: 0
|
||||||
|
|
||||||
|
* - PI_X-LOADER
|
||||||
|
- Generates an image for SPI flash (byte swapped)
|
||||||
|
* - X-LOADER
|
||||||
|
- Generates an image for non-XIP flash
|
||||||
|
* - MLO
|
||||||
|
- Generates an image for SD/MMC/eMMC media
|
||||||
|
* - 2ND
|
||||||
|
- Generates an image for USB, UART and Ethernet
|
||||||
|
* - XIP_X-LOADER
|
||||||
|
- Generates a single stage u-boot for NOR/QSPI XiP
|
||||||
|
|
||||||
|
<INPUT_FILE> is the full path and filename of the public world boot
|
||||||
|
loaderbinary file (depending on the boot media, this is usually
|
||||||
|
either u-boot-spl.bin or u-boot.bin).
|
||||||
|
|
||||||
|
<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)
|
||||||
|
|
||||||
|
.. list-table::
|
||||||
|
:widths: 25 25
|
||||||
|
:header-rows: 0
|
||||||
|
|
||||||
|
* - u-boot-spl_HS_SPI_X-LOADER
|
||||||
|
- byte swapped boot image for SPI flash
|
||||||
|
* - u-boot-spl_HS_X-LOADER
|
||||||
|
- boot image for NAND or SD/MMC/eMMC rawmode
|
||||||
|
* - u-boot-spl_HS_MLO
|
||||||
|
- boot image for SD/MMC/eMMC media
|
||||||
|
* - u-boot-spl_HS_2ND
|
||||||
|
- boot image for USB, UART and Ethernet
|
||||||
|
* - u-boot_HS_XIP_X-LOADER
|
||||||
|
- boot image for NOR or QSPI Xip flash
|
||||||
|
|
||||||
|
<SPL_LOAD_ADDR> is the address at which SOC ROM should load the
|
||||||
|
<INPUT_FILE>
|
||||||
|
|
||||||
|
.. secure_boot_include_start_primary_u_boot
|
||||||
|
|
||||||
|
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:
|
||||||
|
|
||||||
|
.. prompt:: bash
|
||||||
|
:prompts: $
|
||||||
|
|
||||||
|
${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
|
||||||
|
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||||
|
|
||||||
|
.. prompt:: bash
|
||||||
|
:prompts: $
|
||||||
|
|
||||||
|
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.
|
||||||
|
|
||||||
|
.. secure_boot_include_end_primary_u_boot
|
||||||
|
|
||||||
NAND
|
NAND
|
||||||
----
|
----
|
||||||
|
|
||||||
|
|
@ -52,41 +226,53 @@ inserted with the files to write in the first SD slot and that mtdparts
|
||||||
have been configured correctly for the board. All images are first loaded
|
have been configured correctly for the board. All images are first loaded
|
||||||
into memory, then written to NAND.
|
into memory, then written to NAND.
|
||||||
|
|
||||||
Step-1: Building u-boot for NAND boot
|
1. Building u-boot for NAND boot
|
||||||
Set following CONFIGxx options for NAND device.
|
|
||||||
CONFIG_SYS_NAND_PAGE_SIZE number of main bytes in NAND page
|
|
||||||
CONFIG_SYS_NAND_OOBSIZE number of OOB bytes in NAND page
|
|
||||||
CONFIG_SYS_NAND_BLOCK_SIZE number of bytes in NAND erase-block
|
|
||||||
CFG_SYS_NAND_ECCPOS ECC map for NAND page
|
|
||||||
CONFIG_NAND_OMAP_ECCSCHEME (refer doc/README.nand)
|
|
||||||
|
|
||||||
Step-2: Flashing NAND via MMC/SD
|
.. list-table:: CONFIGxx options for NAND device
|
||||||
|
:widths: 25 25
|
||||||
|
:header-rows: 1
|
||||||
|
|
||||||
.. code-block:: text
|
* - Config
|
||||||
|
- Description
|
||||||
|
* - CONFIG_SYS_NAND_PAGE_SIZE
|
||||||
|
- number of main bytes in NAND page
|
||||||
|
* - CONFIG_SYS_NAND_OOBSIZE
|
||||||
|
- number of OOB bytes in NAND page
|
||||||
|
* - CONFIG_SYS_NAND_BLOCK_SIZE
|
||||||
|
- number of bytes in NAND erase-block
|
||||||
|
* - CFG_SYS_NAND_ECCPOS
|
||||||
|
- ECC map for NAND page
|
||||||
|
* - CONFIG_NAND_OMAP_ECCSCHEME
|
||||||
|
- (refer doc/README.nand)
|
||||||
|
|
||||||
# select BOOTSEL to MMC/SD boot and boot from MMC/SD card
|
2. Flashing NAND via MMC/SD
|
||||||
U-Boot # mmc rescan
|
|
||||||
# erase flash
|
|
||||||
U-Boot # nand erase.chip
|
|
||||||
U-Boot # env default -f -a
|
|
||||||
U-Boot # saveenv
|
|
||||||
# flash MLO. Redundant copies of MLO are kept for failsafe
|
|
||||||
U-Boot # load mmc 0 0x82000000 MLO
|
|
||||||
U-Boot # nand write 0x82000000 0x00000 0x20000
|
|
||||||
U-Boot # nand write 0x82000000 0x20000 0x20000
|
|
||||||
U-Boot # nand write 0x82000000 0x40000 0x20000
|
|
||||||
U-Boot # nand write 0x82000000 0x60000 0x20000
|
|
||||||
# flash u-boot.img
|
|
||||||
U-Boot # load mmc 0 0x82000000 u-boot.img
|
|
||||||
U-Boot # nand write 0x82000000 0x80000 0x60000
|
|
||||||
# flash kernel image
|
|
||||||
U-Boot # load mmc 0 0x82000000 uImage
|
|
||||||
U-Boot # nand write 0x82000000 ${nandsrcaddr} ${nandimgsize}
|
|
||||||
# flash filesystem image
|
|
||||||
U-Boot # load mmc 0 0x82000000 filesystem.img
|
|
||||||
U-Boot # nand write 0x82000000 ${loadaddress} 0x300000
|
|
||||||
|
|
||||||
Step-3: Set BOOTSEL pin to select NAND boot, and POR the device.
|
.. prompt:: bash
|
||||||
|
:prompts: =>
|
||||||
|
|
||||||
|
# select BOOTSEL to MMC/SD boot and boot from MMC/SD card
|
||||||
|
mmc rescan
|
||||||
|
# erase flash
|
||||||
|
nand erase.chip
|
||||||
|
env default -f -a
|
||||||
|
saveenv
|
||||||
|
# flash MLO. Redundant copies of MLO are kept for failsafe
|
||||||
|
load mmc 0 0x82000000 MLO
|
||||||
|
nand write 0x82000000 0x00000 0x20000
|
||||||
|
nand write 0x82000000 0x20000 0x20000
|
||||||
|
nand write 0x82000000 0x40000 0x20000
|
||||||
|
nand write 0x82000000 0x60000 0x20000
|
||||||
|
# flash u-boot.img
|
||||||
|
load mmc 0 0x82000000 u-boot.img
|
||||||
|
nand write 0x82000000 0x80000 0x60000
|
||||||
|
# flash kernel image
|
||||||
|
load mmc 0 0x82000000 uImage
|
||||||
|
nand write 0x82000000 ${nandsrcaddr} ${nandimgsize}
|
||||||
|
# flash filesystem image
|
||||||
|
load mmc 0 0x82000000 filesystem.img
|
||||||
|
nand write 0x82000000 ${loadaddress} 0x300000
|
||||||
|
|
||||||
|
3. Set BOOTSEL pin to select NAND boot, and POR the device.
|
||||||
The device should boot from images flashed on NAND device.
|
The device should boot from images flashed on NAND device.
|
||||||
|
|
||||||
|
|
||||||
|
|
@ -107,16 +293,34 @@ Falcon Mode: eMMC
|
||||||
|
|
||||||
The recommended layout in this case is:
|
The recommended layout in this case is:
|
||||||
|
|
||||||
.. code-block:: text
|
.. list-table:: eMMC Recommended Layout
|
||||||
|
:widths: 25 25 50
|
||||||
|
:header-rows: 1
|
||||||
|
|
||||||
MMC BLOCKS |--------------------------------| LOCATION IN BYTES
|
* - MMC Blocks
|
||||||
0x0000 - 0x007F : MBR or GPT table : 0x000000 - 0x020000
|
- Description
|
||||||
0x0080 - 0x00FF : ARGS or FDT file : 0x010000 - 0x020000
|
- Location in bytes
|
||||||
0x0100 - 0x01FF : SPL.backup1 (first copy used) : 0x020000 - 0x040000
|
* - 0x0000 - 0x007F
|
||||||
0x0200 - 0x02FF : SPL.backup2 (second copy used) : 0x040000 - 0x060000
|
- MBR or GPT table
|
||||||
0x0300 - 0x06FF : U-Boot : 0x060000 - 0x0e0000
|
- 0x000000 - 0x020000
|
||||||
0x0700 - 0x08FF : U-Boot Env + Redundant : 0x0e0000 - 0x120000
|
* - 0x0080 - 0x00FF
|
||||||
0x0900 - 0x28FF : Kernel : 0x120000 - 0x520000
|
- ARGS or FDT file
|
||||||
|
- 0x010000 - 0x020000
|
||||||
|
* - 0x0100 - 0x01FF
|
||||||
|
- SPL.backup1 (first copy used)
|
||||||
|
- 0x020000 - 0x040000
|
||||||
|
* - 0x0200 - 0x02FF
|
||||||
|
- SPL.backup2 (second copy used)
|
||||||
|
- 0x040000 - 0x060000
|
||||||
|
* - 0x0300 - 0x06FF
|
||||||
|
- U-Boot
|
||||||
|
- 0x060000 - 0x0e0000
|
||||||
|
* - 0x0700 - 0x08FF
|
||||||
|
- U-Boot Env + Redundant
|
||||||
|
- 0x0e0000 - 0x120000
|
||||||
|
* - 0x0900 - 0x28FF
|
||||||
|
- Kernel
|
||||||
|
- 0x120000 - 0x520000
|
||||||
|
|
||||||
Note that when we run 'spl export' it will prepare to boot the kernel.
|
Note that when we run 'spl export' it will prepare to boot the kernel.
|
||||||
This includes relocation of the uImage from where we loaded it to the entry
|
This includes relocation of the uImage from where we loaded it to the entry
|
||||||
|
|
@ -130,27 +334,28 @@ had a FAT partition (such as on a Beaglebone Black) it is not enough to
|
||||||
write garbage into the area, you must delete it from the partition table
|
write garbage into the area, you must delete it from the partition table
|
||||||
first.
|
first.
|
||||||
|
|
||||||
.. code-block:: text
|
.. prompt:: bash
|
||||||
|
:prompts: =>
|
||||||
|
|
||||||
# Ensure we are able to talk with this mmc device
|
# Ensure we are able to talk with this mmc device
|
||||||
U-Boot # mmc rescan
|
mmc rescan
|
||||||
U-Boot # tftp 81000000 am335x/MLO
|
tftp 81000000 am335x/MLO
|
||||||
# Write to two of the backup locations ROM uses
|
# Write to two of the backup locations ROM uses
|
||||||
U-Boot # mmc write 81000000 100 100
|
mmc write 81000000 100 100
|
||||||
U-Boot # mmc write 81000000 200 100
|
mmc write 81000000 200 100
|
||||||
# Write U-Boot to the location set in the config
|
# Write U-Boot to the location set in the config
|
||||||
U-Boot # tftp 81000000 am335x/u-boot.img
|
tftp 81000000 am335x/u-boot.img
|
||||||
U-Boot # mmc write 81000000 300 400
|
mmc write 81000000 300 400
|
||||||
# Load kernel and device tree into memory, perform export
|
# Load kernel and device tree into memory, perform export
|
||||||
U-Boot # tftp 81000000 am335x/uImage
|
tftp 81000000 am335x/uImage
|
||||||
U-Boot # run findfdt
|
run findfdt
|
||||||
U-Boot # tftp ${fdtaddr} am335x/${fdtfile}
|
tftp ${fdtaddr} am335x/${fdtfile}
|
||||||
U-Boot # run mmcargs
|
run mmcargs
|
||||||
U-Boot # spl export fdt 81000000 - ${fdtaddr}
|
spl export fdt 81000000 - ${fdtaddr}
|
||||||
# Write the updated device tree to MMC
|
# Write the updated device tree to MMC
|
||||||
U-Boot # mmc write ${fdtaddr} 80 80
|
mmc write ${fdtaddr} 80 80
|
||||||
# Write the uImage to MMC
|
# Write the uImage to MMC
|
||||||
U-Boot # mmc write 81000000 900 2000
|
mmc write 81000000 900 2000
|
||||||
|
|
||||||
Falcon Mode: FAT SD cards
|
Falcon Mode: FAT SD cards
|
||||||
-------------------------
|
-------------------------
|
||||||
|
|
@ -161,28 +366,30 @@ the FAT filesystem (only the uImage MUST be for this to function
|
||||||
afterwards) along with a Falcon Mode aware MLO and the FAT partition has
|
afterwards) along with a Falcon Mode aware MLO and the FAT partition has
|
||||||
already been created and marked bootable:
|
already been created and marked bootable:
|
||||||
|
|
||||||
.. code-block:: text
|
.. prompt:: bash
|
||||||
|
:prompts: =>
|
||||||
|
|
||||||
U-Boot # mmc rescan
|
mmc rescan
|
||||||
# Load kernel and device tree into memory, perform export
|
# Load kernel and device tree into memory, perform export
|
||||||
U-Boot # load mmc 0:1 ${loadaddr} uImage
|
load mmc 0:1 ${loadaddr} uImage
|
||||||
U-Boot # run findfdt
|
run findfdt
|
||||||
U-Boot # load mmc 0:1 ${fdtaddr} ${fdtfile}
|
load mmc 0:1 ${fdtaddr} ${fdtfile}
|
||||||
U-Boot # run mmcargs
|
run mmcargs
|
||||||
U-Boot # spl export fdt ${loadaddr} - ${fdtaddr}
|
spl export fdt ${loadaddr} - ${fdtaddr}
|
||||||
|
|
||||||
This will print a number of lines and then end with something like:
|
This will print a number of lines and then end with something like:
|
||||||
|
|
||||||
.. code-block:: text
|
.. code-block:: bash
|
||||||
|
|
||||||
Using Device Tree in place at 80f80000, end 80f85928
|
Using Device Tree in place at 80f80000, end 80f85928
|
||||||
Using Device Tree in place at 80f80000, end 80f88928
|
Using Device Tree in place at 80f80000, end 80f88928
|
||||||
|
|
||||||
So then you:
|
So then you:
|
||||||
|
|
||||||
.. code-block:: text
|
.. prompt:: bash
|
||||||
|
:prompts: =>
|
||||||
|
|
||||||
U-Boot # fatwrite mmc 0:1 0x80f80000 args 8928
|
fatwrite mmc 0:1 0x80f80000 args 8928
|
||||||
|
|
||||||
Falcon Mode: NAND
|
Falcon Mode: NAND
|
||||||
-----------------
|
-----------------
|
||||||
|
|
@ -193,14 +400,15 @@ already located on the NAND somewhere (such as filesystem or mtd partition)
|
||||||
along with a Falcon Mode aware MLO written to the correct locations for
|
along with a Falcon Mode aware MLO written to the correct locations for
|
||||||
booting and mtdparts have been configured correctly for the board:
|
booting and mtdparts have been configured correctly for the board:
|
||||||
|
|
||||||
.. code-block:: text
|
.. prompt:: bash
|
||||||
|
:prompts: =>
|
||||||
|
|
||||||
U-Boot # nand read ${loadaddr} kernel
|
nand read ${loadaddr} kernel
|
||||||
U-Boot # load nand rootfs ${fdtaddr} /boot/am335x-evm.dtb
|
load nand rootfs ${fdtaddr} /boot/am335x-evm.dtb
|
||||||
U-Boot # run nandargs
|
run nandargs
|
||||||
U-Boot # spl export fdt ${loadaddr} - ${fdtaddr}
|
spl export fdt ${loadaddr} - ${fdtaddr}
|
||||||
U-Boot # nand erase.part u-boot-spl-os
|
nand erase.part u-boot-spl-os
|
||||||
U-Boot # nand write ${fdtaddr} u-boot-spl-os
|
nand write ${fdtaddr} u-boot-spl-os
|
||||||
|
|
||||||
USB device
|
USB device
|
||||||
----------
|
----------
|
||||||
|
|
@ -217,27 +425,35 @@ The output of the 'dm tree' command shows which driver is bound to which
|
||||||
device, so the user can easily configure their platform differently from
|
device, so the user can easily configure their platform differently from
|
||||||
the command line:
|
the command line:
|
||||||
|
|
||||||
|
.. prompt:: bash
|
||||||
|
:prompts: =>
|
||||||
|
|
||||||
|
dm tree
|
||||||
|
|
||||||
.. code-block:: text
|
.. code-block:: text
|
||||||
|
|
||||||
=> dm tree
|
Class Index Probed Driver Name
|
||||||
Class Index Probed Driver Name
|
-----------------------------------------------------------
|
||||||
-----------------------------------------------------------
|
[...]
|
||||||
[...]
|
misc 0 [ + ] ti-musb-wrapper | |-- usb@47400000
|
||||||
misc 0 [ + ] ti-musb-wrapper | |-- usb@47400000
|
usb 0 [ + ] ti-musb-peripheral | | |-- usb@47401000
|
||||||
usb 0 [ + ] ti-musb-peripheral | | |-- usb@47401000
|
ethernet 1 [ + ] usb_ether | | | `-- usb_ether
|
||||||
ethernet 1 [ + ] usb_ether | | | `-- usb_ether
|
bootdev 3 [ ] eth_bootdev | | | `-- usb_ether.bootdev
|
||||||
bootdev 3 [ ] eth_bootdev | | | `-- usb_ether.bootdev
|
usb 0 [ ] ti-musb-host | | `-- usb@47401800
|
||||||
usb 0 [ ] ti-musb-host | | `-- usb@47401800
|
|
||||||
|
|
||||||
Typically here any network command performed using the usb_ether
|
Typically here any network command performed using the usb_ether
|
||||||
interface would work, while using other gadgets would fail:
|
interface would work, while using other gadgets would fail:
|
||||||
|
|
||||||
|
.. prompt:: bash
|
||||||
|
:prompts: =>
|
||||||
|
|
||||||
|
fastboot usb 0
|
||||||
|
|
||||||
.. code-block:: text
|
.. code-block:: text
|
||||||
|
|
||||||
=> fastboot usb 0
|
All UDC in use (1 available), use the unbind command
|
||||||
All UDC in use (1 available), use the unbind command
|
g_dnl_register: failed!, error: -19
|
||||||
g_dnl_register: failed!, error: -19
|
exit not allowed from main input shell.
|
||||||
exit not allowed from main input shell.
|
|
||||||
|
|
||||||
As hinted by the primary error message, the only controller available
|
As hinted by the primary error message, the only controller available
|
||||||
(usb@47401000) is currently bound to the usb_ether driver, which makes
|
(usb@47401000) is currently bound to the usb_ether driver, which makes
|
||||||
|
|
@ -246,20 +462,25 @@ least from a bootloader point of view). The solution here would be to
|
||||||
use the unbind command specifying the class and index parameters (as
|
use the unbind command specifying the class and index parameters (as
|
||||||
shown above in the 'dm tree' output) to target the driver to unbind:
|
shown above in the 'dm tree' output) to target the driver to unbind:
|
||||||
|
|
||||||
.. code-block:: text
|
.. prompt:: bash
|
||||||
|
:prompts: =>
|
||||||
|
|
||||||
=> unbind ethernet 1
|
unbind ethernet 1
|
||||||
|
|
||||||
The output of the 'dm tree' command now shows the availability of the
|
The output of the 'dm tree' command now shows the availability of the
|
||||||
first USB device controller, the fastboot gadget will now be able to
|
first USB device controller, the fastboot gadget will now be able to
|
||||||
bind with it:
|
bind with it:
|
||||||
|
|
||||||
|
.. prompt:: bash
|
||||||
|
:prompts: =>
|
||||||
|
|
||||||
|
dm tree
|
||||||
|
|
||||||
.. code-block:: text
|
.. code-block:: text
|
||||||
|
|
||||||
=> dm tree
|
Class Index Probed Driver Name
|
||||||
Class Index Probed Driver Name
|
-----------------------------------------------------------
|
||||||
-----------------------------------------------------------
|
[...]
|
||||||
[...]
|
misc 0 [ + ] ti-musb-wrapper | |-- usb@47400000
|
||||||
misc 0 [ + ] ti-musb-wrapper | |-- usb@47400000
|
usb 0 [ ] ti-musb-peripheral | | |-- usb@47401000
|
||||||
usb 0 [ ] ti-musb-peripheral | | |-- usb@47401000
|
usb 0 [ ] ti-musb-host | | `-- usb@47401800
|
||||||
usb 0 [ ] ti-musb-host | | `-- usb@47401800
|
|
||||||
|
|
|
||||||
188
doc/board/ti/am43xx_evm.rst
Normal file
188
doc/board/ti/am43xx_evm.rst
Normal file
|
|
@ -0,0 +1,188 @@
|
||||||
|
.. SPDX-License-Identifier: GPL-2.0+ OR BSD-3-Clause
|
||||||
|
.. sectionauthor:: Neha Malcom Francis <n-francis@ti.com>
|
||||||
|
|
||||||
|
AM43xx Generation
|
||||||
|
=================
|
||||||
|
|
||||||
|
Secure Boot
|
||||||
|
-----------
|
||||||
|
|
||||||
|
.. include:: am335x_evm.rst
|
||||||
|
:start-after: .. secure_boot_include_start_config_ti_secure_device
|
||||||
|
:end-before: .. secure_boot_include_end_config_ti_secure_device
|
||||||
|
|
||||||
|
.. include:: am335x_evm.rst
|
||||||
|
:start-after: .. secure_boot_include_start_spl_boot
|
||||||
|
:end-before: .. secure_boot_include_end_spl_boot
|
||||||
|
|
||||||
|
<IMAGE_FLAG> is a value that specifies the type of the image to
|
||||||
|
generate OR the action the image generation tool will take. Valid
|
||||||
|
values are:
|
||||||
|
|
||||||
|
.. list-table::
|
||||||
|
:widths: 25 25
|
||||||
|
:header-rows: 0
|
||||||
|
|
||||||
|
* - SPI_X-LOADER
|
||||||
|
- Generates an image for SPI flash (byte swapped)
|
||||||
|
* - XIP_X-LOADER
|
||||||
|
- Generates a single stage u-boot for NOR/QSPI XiP
|
||||||
|
* - ISSW
|
||||||
|
- Generates an image for all other boot modes
|
||||||
|
|
||||||
|
<INPUT_FILE> is the full path and filename of the public world boot
|
||||||
|
loaderbinary file (depending on the boot media, this is usually
|
||||||
|
either u-boot-spl.bin or u-boot.bin).
|
||||||
|
|
||||||
|
<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)
|
||||||
|
|
||||||
|
.. list-table::
|
||||||
|
:widths: 25 25
|
||||||
|
:header-rows: 0
|
||||||
|
|
||||||
|
* - u-boot-spl_HS_SPI_X-LOADER
|
||||||
|
- byte swapped boot image for SPI flash
|
||||||
|
* - u-boot_HS_XIP_X-LOADER
|
||||||
|
- boot image for NOR or QSPI Xip flash
|
||||||
|
* - u-boot-spl_HS_ISSW
|
||||||
|
- boot image for all other boot media
|
||||||
|
|
||||||
|
|
||||||
|
<SPL_LOAD_ADDR> is the address at which SOC ROM should load the
|
||||||
|
<INPUT_FILE>
|
||||||
|
|
||||||
|
.. include:: am335x_evm.rst
|
||||||
|
:start-after: .. secure_boot_include_start_primary_u_boot
|
||||||
|
:end-before: .. secure_boot_include_end_primary_u_boot
|
||||||
|
|
||||||
|
.. qspi_boot_support_include_start
|
||||||
|
|
||||||
|
QSPI U-Boot support
|
||||||
|
-------------------
|
||||||
|
|
||||||
|
Host processor is connected to serial flash device via qpsi
|
||||||
|
interface. QSPI is a kind of spi module that allows single,
|
||||||
|
dual and quad read access to external spi devices. The module
|
||||||
|
has a memory mapped interface which provide direct interface
|
||||||
|
for accessing data form external spi devices.
|
||||||
|
|
||||||
|
The one QSPI in the device is primarily intended for fast booting
|
||||||
|
from Quad SPI flash devices.
|
||||||
|
|
||||||
|
Usecase
|
||||||
|
^^^^^^^
|
||||||
|
|
||||||
|
MLO/u-boot.img will be flashed from SD/MMC to the flash device
|
||||||
|
using serial flash erase and write commands. Then, switch settings
|
||||||
|
will be changed to qspi boot. Then, the ROM code will read MLO
|
||||||
|
from the predefined location in the flash, where it was flashed and
|
||||||
|
execute it after storing it in SDRAM. Then, the MLO will read
|
||||||
|
u-boot.img from flash and execute it from SDRAM.
|
||||||
|
|
||||||
|
SPI mode
|
||||||
|
^^^^^^^^
|
||||||
|
|
||||||
|
SPI mode uses mtd spi framework for transfer and reception of data.
|
||||||
|
Can be used in:
|
||||||
|
|
||||||
|
#. Normal mode: use single pin for transfers
|
||||||
|
#. Dual Mode: use two pins for transfers.
|
||||||
|
#. Quad mode: use four pin for transfer
|
||||||
|
|
||||||
|
Memory mapped read mode
|
||||||
|
^^^^^^^^^^^^^^^^^^^^^^^
|
||||||
|
|
||||||
|
In this, SPI controller is configured using configuration port and then
|
||||||
|
controller is switched to memory mapped port for data read.
|
||||||
|
|
||||||
|
Driver
|
||||||
|
^^^^^^
|
||||||
|
|
||||||
|
drivers/qspi/ti_qspi.c
|
||||||
|
- File which is responsible for configuring the
|
||||||
|
qspi controller and also for providing the low level api which
|
||||||
|
is responsible for transferring the datas from host controller
|
||||||
|
to flash device and vice versa.
|
||||||
|
|
||||||
|
.. qspi_boot_support_include_end
|
||||||
|
|
||||||
|
Testing
|
||||||
|
^^^^^^^
|
||||||
|
|
||||||
|
These are the testing details of qspi flash driver with Macronix M25L51235
|
||||||
|
flash device.
|
||||||
|
|
||||||
|
The test includes
|
||||||
|
- probing the flash device
|
||||||
|
- erasing the flash device
|
||||||
|
- Writing to flash
|
||||||
|
- Reading the contents of the flash.
|
||||||
|
|
||||||
|
Test Log
|
||||||
|
|
||||||
|
.. code-block:: bash
|
||||||
|
|
||||||
|
Hit any key to stop autoboot: 0
|
||||||
|
=> sf probe 0
|
||||||
|
SF: Detected MX25L51235F with page size 256 Bytes, erase size 64 KiB, total 64 MiB, mapped at 30000000
|
||||||
|
=> sf erase 0 0x80000
|
||||||
|
SF: 524288 bytes @ 0x0 Erased: OK
|
||||||
|
=> mw 81000000 0xdededede 0x40000
|
||||||
|
=> sf write 81000000 0 0x40000
|
||||||
|
SF: 262144 bytes @ 0x0 Written: OK
|
||||||
|
=> sf read 82000000 0 0x40000
|
||||||
|
SF: 262144 bytes @ 0x0 Read: OK
|
||||||
|
=> md 0x82000000
|
||||||
|
82000000: dededede dededede dededede dededede ................
|
||||||
|
82000010: dededede dededede dededede dededede ................
|
||||||
|
82000020: dededede dededede dededede dededede ................
|
||||||
|
82000030: dededede dededede dededede dededede ................
|
||||||
|
82000040: dededede dededede dededede dededede ................
|
||||||
|
82000050: dededede dededede dededede dededede ................
|
||||||
|
82000060: dededede dededede dededede dededede ................
|
||||||
|
82000070: dededede dededede dededede dededede ................
|
||||||
|
82000080: dededede dededede dededede dededede ................
|
||||||
|
82000090: dededede dededede dededede dededede ................
|
||||||
|
820000a0: dededede dededede dededede dededede ................
|
||||||
|
820000b0: dededede dededede dededede dededede ................
|
||||||
|
820000c0: dededede dededede dededede dededede ................
|
||||||
|
820000d0: dededede dededede dededede dededede ................
|
||||||
|
820000e0: dededede dededede dededede dededede ................
|
||||||
|
820000f0: dededede dededede dededede dededede ................
|
||||||
|
=> md 0x82010000
|
||||||
|
82010000: dededede dededede dededede dededede ................
|
||||||
|
82010010: dededede dededede dededede dededede ................
|
||||||
|
82010020: dededede dededede dededede dededede ................
|
||||||
|
82010030: dededede dededede dededede dededede ................
|
||||||
|
82010040: dededede dededede dededede dededede ................
|
||||||
|
82010050: dededede dededede dededede dededede ................
|
||||||
|
82010060: dededede dededede dededede dededede ................
|
||||||
|
82010070: dededede dededede dededede dededede ................
|
||||||
|
82010080: dededede dededede dededede dededede ................
|
||||||
|
82010090: dededede dededede dededede dededede ................
|
||||||
|
820100a0: dededede dededede dededede dededede ................
|
||||||
|
820100b0: dededede dededede dededede dededede ................
|
||||||
|
820100c0: dededede dededede dededede dededede ................
|
||||||
|
820100d0: dededede dededede dededede dededede ................
|
||||||
|
820100e0: dededede dededede dededede dededede ................
|
||||||
|
820100f0: dededede dededede dededede dededede ................
|
||||||
|
=> md 0x82030000
|
||||||
|
82030000: dededede dededede dededede dededede ................
|
||||||
|
82030010: dededede dededede dededede dededede ................
|
||||||
|
82030020: dededede dededede dededede dededede ................
|
||||||
|
82030030: dededede dededede dededede dededede ................
|
||||||
|
82030040: dededede dededede dededede dededede ................
|
||||||
|
82030050: dededede dededede dededede dededede ................
|
||||||
|
82030060: dededede dededede dededede dededede ................
|
||||||
|
82030070: dededede dededede dededede dededede ................
|
||||||
|
82030080: dededede dededede dededede dededede ................
|
||||||
|
82030090: dededede dededede dededede dededede ................
|
||||||
|
820300a0: dededede dededede dededede dededede ................
|
||||||
|
820300b0: dededede dededede dededede dededede ................
|
||||||
|
820300c0: dededede dededede dededede dededede ................
|
||||||
|
820300d0: dededede dededede dededede dededede ................
|
||||||
|
820300e0: dededede dededede dededede dededede ................
|
||||||
|
820300f0: dededede dededede dededede dededede ................
|
||||||
139
doc/board/ti/dra7xx_evm.rst
Normal file
139
doc/board/ti/dra7xx_evm.rst
Normal file
|
|
@ -0,0 +1,139 @@
|
||||||
|
.. SPDX-License-Identifier: GPL-2.0+ OR BSD-3-Clause
|
||||||
|
.. sectionauthor:: Neha Malcom Francis <n-francis@ti.com>
|
||||||
|
|
||||||
|
DRA7xx Generation
|
||||||
|
=================
|
||||||
|
|
||||||
|
Secure Boot
|
||||||
|
-----------
|
||||||
|
|
||||||
|
.. include:: am335x_evm.rst
|
||||||
|
:start-after: .. secure_boot_include_start_config_ti_secure_device
|
||||||
|
:end-before: .. secure_boot_include_end_config_ti_secure_device
|
||||||
|
|
||||||
|
.. include:: am335x_evm.rst
|
||||||
|
:start-after: .. secure_boot_include_start_spl_boot
|
||||||
|
:end-before: .. secure_boot_include_end_spl_boot
|
||||||
|
|
||||||
|
<IMAGE_FLAG> is a value that specifies the type of the image to
|
||||||
|
generate OR the action the image generation tool will take. Valid
|
||||||
|
values are:
|
||||||
|
|
||||||
|
.. list-table::
|
||||||
|
:widths: 25 25
|
||||||
|
:header-rows: 0
|
||||||
|
|
||||||
|
* - X-LOADER
|
||||||
|
- Generates an image for NOR or QSPI boot modes
|
||||||
|
* - MLO
|
||||||
|
- Generates an image for NOR or QSPI boot modes
|
||||||
|
* - ULO
|
||||||
|
- Generates an image for USB/UART peripheral boot modes
|
||||||
|
|
||||||
|
<INPUT_FILE> is the full path and filename of the public world boot
|
||||||
|
loaderbinary file (for this platform, this is always u-boot-spl.bin).
|
||||||
|
|
||||||
|
<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)
|
||||||
|
|
||||||
|
.. list-table::
|
||||||
|
:widths: 25 25
|
||||||
|
:header-rows: 0
|
||||||
|
|
||||||
|
* - u-boot-spl_HS_SPI_X-LOADER
|
||||||
|
- boot image for SD/MMC/eMMC. This image is
|
||||||
|
copied to a file named MLO, which is the name that
|
||||||
|
the device ROM bootloader requires for loading from
|
||||||
|
the FAT partition of an SD card (same as on
|
||||||
|
non-secure devices)
|
||||||
|
* - u-boot-spl_HS_ULO
|
||||||
|
- boot image for USB/UART peripheral boot modes
|
||||||
|
* - u-boot-spl_HS_X-LOADER
|
||||||
|
- boot image for all other flash memories
|
||||||
|
including QSPI and NOR flash
|
||||||
|
|
||||||
|
<SPL_LOAD_ADDR> is the address at which SOC ROM should load the
|
||||||
|
<INPUT_FILE>
|
||||||
|
|
||||||
|
.. include:: am335x_evm.rst
|
||||||
|
:start-after: .. secure_boot_include_start_primary_u_boot
|
||||||
|
:end-before: .. secure_boot_include_end_primary_u_boot
|
||||||
|
|
||||||
|
eMMC Boot Partition Use
|
||||||
|
-----------------------
|
||||||
|
|
||||||
|
It is possible, depending on SYSBOOT configuration to boot from the eMMC
|
||||||
|
boot partitions using (name depending on documentation referenced)
|
||||||
|
Alternative Boot operation mode or Boot Sequence Option 1/2. In this
|
||||||
|
example we load MLO and u-boot.img from the build into DDR and then use
|
||||||
|
'mmc bootbus' to set the required rate (see TRM) and 'mmc partconfig' to
|
||||||
|
set boot0 as the boot device.
|
||||||
|
|
||||||
|
.. prompt:: bash
|
||||||
|
:prompts: =>
|
||||||
|
|
||||||
|
setenv autoload no
|
||||||
|
usb start
|
||||||
|
dhcp
|
||||||
|
mmc dev 1 1
|
||||||
|
tftp ${loadaddr} dra7xx/MLO
|
||||||
|
mmc write ${loadaddr} 0 100
|
||||||
|
tftp ${loadaddr} dra7xx/u-boot.img
|
||||||
|
mmc write ${loadaddr} 300 400
|
||||||
|
mmc bootbus 1 2 0 2
|
||||||
|
mmc partconf 1 1 1 0
|
||||||
|
mmc rst-function 1 1
|
||||||
|
|
||||||
|
.. include:: am43xx_evm.rst
|
||||||
|
:start-after: qspi_boot_support_include_start
|
||||||
|
:end-before: qspi_boot_support_include_end
|
||||||
|
|
||||||
|
Testing
|
||||||
|
^^^^^^^
|
||||||
|
|
||||||
|
Build the patched U-Boot and load MLO/u-boot.img.
|
||||||
|
|
||||||
|
Boot from another medium like MMC
|
||||||
|
|
||||||
|
.. prompt:: bash
|
||||||
|
|
||||||
|
=> mmc dev 0
|
||||||
|
mmc0 is current device
|
||||||
|
=> fatload mmc 0 0x82000000 MLO
|
||||||
|
reading MLO
|
||||||
|
55872 bytes read in 8 ms (6.7 MiB/s)
|
||||||
|
=> fatload mmc 0 0x83000000 u-boot.img
|
||||||
|
reading u-boot.img
|
||||||
|
248600 bytes read in 19 ms (12.5 MiB/s)
|
||||||
|
|
||||||
|
Commands to erase/write u-boot/MLO to flash device
|
||||||
|
|
||||||
|
.. prompt:: bash
|
||||||
|
|
||||||
|
=> sf probe 0
|
||||||
|
SF: Detected S25FL256S_64K with page size 256 Bytes, erase size 64 KiB, total 32 MiB, mapped at 5c000000
|
||||||
|
=> sf erase 0 0x10000
|
||||||
|
SF: 65536 bytes @ 0x0 Erased: OK
|
||||||
|
=> sf erase 0x20000 0x10000
|
||||||
|
SF: 65536 bytes @ 0x20000 Erased: OK
|
||||||
|
=> sf erase 0x30000 0x10000
|
||||||
|
SF: 65536 bytes @ 0x30000 Erased: OK
|
||||||
|
=> sf erase 0x40000 0x10000
|
||||||
|
SF: 65536 bytes @ 0x40000 Erased: OK
|
||||||
|
=> sf erase 0x50000 0x10000
|
||||||
|
SF: 65536 bytes @ 0x50000 Erased: OK
|
||||||
|
=> sf erase 0x60000 0x10000
|
||||||
|
SF: 65536 bytes @ 0x60000 Erased: OK
|
||||||
|
=> sf write 82000000 0 0x10000
|
||||||
|
SF: 65536 bytes @ 0x0 Written: OK
|
||||||
|
=> sf write 83000000 0x20000 0x60000
|
||||||
|
SF: 393216 bytes @ 0x20000 Written: OK
|
||||||
|
|
||||||
|
Next, set sysboot to QSPI-1 boot mode(SYSBOOT[5:0] = 100110) and power
|
||||||
|
on. ROM should find the GP header at offset 0 and load/execute SPL. SPL
|
||||||
|
then detects that ROM was in QSPI-1 mode (boot code 10) and attempts to
|
||||||
|
find a U-Boot image header at offset 0x20000 (set in the config file)
|
||||||
|
and proceeds to load that image using the U-Boot image payload offset/size
|
||||||
|
from the header. It will then start U-Boot.
|
||||||
|
|
@ -7,4 +7,7 @@ Texas Instruments
|
||||||
:maxdepth: 2
|
:maxdepth: 2
|
||||||
|
|
||||||
am335x_evm
|
am335x_evm
|
||||||
|
am43xx_evm
|
||||||
|
dra7xx_evm
|
||||||
|
ks2_evm
|
||||||
k3
|
k3
|
||||||
|
|
|
||||||
306
doc/board/ti/ks2_evm.rst
Normal file
306
doc/board/ti/ks2_evm.rst
Normal file
|
|
@ -0,0 +1,306 @@
|
||||||
|
.. SPDX-License-Identifier: GPL-2.0+ OR BSD-3-Clause
|
||||||
|
.. sectionauthor:: Neha Malcom Francis <n-francis@ti.com>
|
||||||
|
|
||||||
|
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:
|
||||||
|
|
||||||
|
- http://www.advantech.com/Support/TI-EVM/EVMK2HX_sd.aspx
|
||||||
|
- https://www.einfochips.com/index.php/partnerships/texas-instruments/k2e-evm.html
|
||||||
|
- https://www.einfochips.com/index.php/partnerships/texas-instruments/k2l-evm.html
|
||||||
|
|
||||||
|
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: http://www.ti.com/product/tci6638k2k
|
||||||
|
K2H: http://www.ti.com/product/tci6638k2h
|
||||||
|
|
||||||
|
The K2E SoC details are available at
|
||||||
|
http://www.ti.com/lit/ds/symlink/66ak2e05.pdf
|
||||||
|
|
||||||
|
The K2L SoC details are available at
|
||||||
|
http://www.ti.com/lit/ds/symlink/tci6630k2l.pdf
|
||||||
|
|
||||||
|
The K2G SoC details are available at
|
||||||
|
http://www.ti.com/lit/ds/symlink/66ak2g02.pdf
|
||||||
|
|
||||||
|
Board Configuration
|
||||||
|
-------------------
|
||||||
|
|
||||||
|
Some of the peripherals that are configured by U-Boot
|
||||||
|
|
||||||
|
.. list-table::
|
||||||
|
:widths: 10 10 10 10 10 10 10 10
|
||||||
|
:header-rows: 1
|
||||||
|
|
||||||
|
* -
|
||||||
|
- 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:
|
||||||
|
|
||||||
|
.. prompt:: bash
|
||||||
|
:prompts: $
|
||||||
|
|
||||||
|
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.
|
||||||
|
|
||||||
|
`<http://processors.wiki.ti.com/index.php/MCSDK_UG_Chapter_Getting_Started#Installing_Code_Composer_Studio>`_
|
||||||
|
|
||||||
|
Use u-boot.bin from the build folder for loading and running U-Boot binary
|
||||||
|
on EVM. Follow instructions at:
|
||||||
|
|
||||||
|
- K2HK http://processors.wiki.ti.com/index.php/EVMK2H_Hardware_Setup
|
||||||
|
- K2E http://processors.wiki.ti.com/index.php/EVMK2E_Hardware_Setup
|
||||||
|
- K2L http://processors.wiki.ti.com/index.php/TCIEVMK2L_Hardware_Setup
|
||||||
|
- K2G http://processors.wiki.ti.com/index.php/66AK2G02_GP_EVM_Hardware_Setup
|
||||||
|
|
||||||
|
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
|
||||||
|
|
||||||
|
`<http://processors.wiki.ti.com/index.php/MCSDK_UG_Chapter_Exploring#Loading_and_Running_U-Boot_on_EVM_through_CCS>`_
|
||||||
|
|
||||||
|
The instructions provided in the above link uses a script for
|
||||||
|
loading the U-Boot binary on the target EVM. Instead do the following:-
|
||||||
|
|
||||||
|
#. 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".
|
||||||
|
#. 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.
|
||||||
|
#. Click View -> Registers from the top level menu to view registers window.
|
||||||
|
#. From Registers, window expand "Core Registers" to view PC. Edit PC value
|
||||||
|
to be 0xc000000. From the "Run" top level menu, select "Free Run"
|
||||||
|
#. The U-Boot prompt is shown at the Tera Term/ Hyper terminal console as
|
||||||
|
below and type any key to stop autoboot as instructed.
|
||||||
|
|
||||||
|
.. code-block:: bash
|
||||||
|
|
||||||
|
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.
|
||||||
|
|
||||||
|
.. prompt:: bash
|
||||||
|
:prompts: =>
|
||||||
|
|
||||||
|
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
|
||||||
|
|
||||||
|
`<http://processors.wiki.ti.com/index.php/*_Hardware_Setup>`_
|
||||||
|
|
||||||
|
6. 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.
|
||||||
|
|
||||||
|
.. prompt:: bash
|
||||||
|
:prompts: =>
|
||||||
|
|
||||||
|
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
|
||||||
|
|
||||||
|
`<http://processors.wiki.ti.com/index.php/>`_
|
||||||
|
|
||||||
|
under Hardware Setup
|
||||||
|
|
||||||
|
6. 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
|
||||||
|
|
||||||
|
.. prompt:: bash
|
||||||
|
|
||||||
|
BMC> bootmode #4
|
||||||
|
MBC> reboot
|
||||||
|
|
||||||
|
3. 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
|
||||||
|
|
||||||
|
`<http://processors.wiki.ti.com/index.php/66AK2G02_GP_EVM_Hardware_Setup>`_
|
||||||
|
|
||||||
|
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
|
||||||
|
-----------
|
||||||
|
|
||||||
|
.. include:: am335x_evm.rst
|
||||||
|
:start-after: .. secure_boot_include_start_config_ti_secure_device
|
||||||
|
:end-before: .. secure_boot_include_end_config_ti_secure_device
|
||||||
|
|
||||||
|
.. include:: am335x_evm.rst
|
||||||
|
:start-after: .. secure_boot_include_start_spl_boot
|
||||||
|
:end-before: .. secure_boot_include_end_spl_boot
|
||||||
|
|
||||||
|
<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)
|
||||||
|
|
||||||
|
.. list-table::
|
||||||
|
:widths: 10 20
|
||||||
|
:header-rows: 0
|
||||||
|
|
||||||
|
* - 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.
|
||||||
|
|
||||||
|
.. include:: am335x_evm.rst
|
||||||
|
:start-after: .. secure_boot_include_start_primary_u_boot
|
||||||
|
:end-before: .. secure_boot_include_end_primary_u_boot
|
||||||
Loading…
Add table
Reference in a new issue