Mirrors/u-boot
2
0
Fork 0
mirror of https://github.com/AsahiLinux/u-boot synced 2024-11-10 07:04:28 +00:00
Code Issues Projects Releases Packages Wiki Activity

doc: board: ti: Move documentation from README to .rst

Browse source 
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 2023-09-08 15:06:16 +05:30 committed by Heinrich Schuchardt
parent 129048a3b7
commit 7314ba2bf8
11 changed files with 959 additions and 718 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

26
board/ti/dra7xx/README
View file

@ -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

194
board/ti/ks2_evm/README
View file

@ -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.

226
doc/README.ti-secure
View file

@ -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.

76
doc/SPI/README.ti_qspi_am43x_test
View file

@ -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 ................

47
doc/SPI/README.ti_qspi_dra_test
View file

@ -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.

47
doc/SPI/README.ti_qspi_flash
View file

@ -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.

425
doc/board/ti/am335x_evm.rst
View file

@ -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
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
----
@ -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
into memory, then written to NAND.
Step-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)
1. Building u-boot for NAND boot
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
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
2. Flashing NAND via MMC/SD
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.
@ -107,16 +293,34 @@ Falcon Mode: eMMC
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
0x0000 - 0x007F : MBR or GPT table : 0x000000 - 0x020000
0x0080 - 0x00FF : 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
* - MMC Blocks
- Description
- Location in bytes
* - 0x0000 - 0x007F
- MBR or GPT table
- 0x000000 - 0x020000
* - 0x0080 - 0x00FF
- 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.
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
first.
.. code-block:: text
.. prompt:: bash
:prompts: =>
# Ensure we are able to talk with this mmc device
U-Boot # mmc rescan
U-Boot # tftp 81000000 am335x/MLO
# Write to two of the backup locations ROM uses
U-Boot # mmc write 81000000 100 100
U-Boot # mmc write 81000000 200 100
# Write U-Boot to the location set in the config
U-Boot # tftp 81000000 am335x/u-boot.img
U-Boot # mmc write 81000000 300 400
# Load kernel and device tree into memory, perform export
U-Boot # tftp 81000000 am335x/uImage
U-Boot # run findfdt
U-Boot # tftp ${fdtaddr} am335x/${fdtfile}
U-Boot # run mmcargs
U-Boot # spl export fdt 81000000 - ${fdtaddr}
# Write the updated device tree to MMC
U-Boot # mmc write ${fdtaddr} 80 80
# Write the uImage to MMC
U-Boot # mmc write 81000000 900 2000
# Ensure we are able to talk with this mmc device
mmc rescan
tftp 81000000 am335x/MLO
# Write to two of the backup locations ROM uses
mmc write 81000000 100 100
mmc write 81000000 200 100
# Write U-Boot to the location set in the config
tftp 81000000 am335x/u-boot.img
mmc write 81000000 300 400
# Load kernel and device tree into memory, perform export
tftp 81000000 am335x/uImage
run findfdt
tftp ${fdtaddr} am335x/${fdtfile}
run mmcargs
spl export fdt 81000000 - ${fdtaddr}
# Write the updated device tree to MMC
mmc write ${fdtaddr} 80 80
# Write the uImage to MMC
mmc write 81000000 900 2000
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
already been created and marked bootable:
.. code-block:: text
.. prompt:: bash
:prompts: =>
U-Boot # mmc rescan
# Load kernel and device tree into memory, perform export
U-Boot # load mmc 0:1 ${loadaddr} uImage
U-Boot # run findfdt
U-Boot # load mmc 0:1 ${fdtaddr} ${fdtfile}
U-Boot # run mmcargs
U-Boot # spl export fdt ${loadaddr} - ${fdtaddr}
mmc rescan
# Load kernel and device tree into memory, perform export
load mmc 0:1 ${loadaddr} uImage
run findfdt
load mmc 0:1 ${fdtaddr} ${fdtfile}
run mmcargs
spl export fdt ${loadaddr} - ${fdtaddr}
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 80f88928
Using Device Tree in place at 80f80000, end 80f85928
Using Device Tree in place at 80f80000, end 80f88928
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
-----------------
@ -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
booting and mtdparts have been configured correctly for the board:
.. code-block:: text
.. prompt:: bash
:prompts: =>
U-Boot # nand read ${loadaddr} kernel
U-Boot # load nand rootfs ${fdtaddr} /boot/am335x-evm.dtb
U-Boot # run nandargs
U-Boot # spl export fdt ${loadaddr} - ${fdtaddr}
U-Boot # nand erase.part u-boot-spl-os
U-Boot # nand write ${fdtaddr} u-boot-spl-os
nand read ${loadaddr} kernel
load nand rootfs ${fdtaddr} /boot/am335x-evm.dtb
run nandargs
spl export fdt ${loadaddr} - ${fdtaddr}
nand erase.part u-boot-spl-os
nand write ${fdtaddr} u-boot-spl-os
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
the command line:
.. prompt:: bash
:prompts: =>
dm tree
.. code-block:: text
=> dm tree
Class Index Probed Driver Name
-----------------------------------------------------------
[...]
misc 0 [ + ] ti-musb-wrapper | |-- usb@47400000
usb 0 [ + ] ti-musb-peripheral | | |-- usb@47401000
ethernet 1 [ + ] usb_ether | | | `-- usb_ether
bootdev 3 [ ] eth_bootdev | | | `-- usb_ether.bootdev
usb 0 [ ] ti-musb-host | | `-- usb@47401800
Class Index Probed Driver Name
-----------------------------------------------------------
[...]
misc 0 [ + ] ti-musb-wrapper | |-- usb@47400000
usb 0 [ + ] ti-musb-peripheral | | |-- usb@47401000
ethernet 1 [ + ] usb_ether | | | `-- usb_ether
bootdev 3 [ ] eth_bootdev | | | `-- usb_ether.bootdev
usb 0 [ ] ti-musb-host | | `-- usb@47401800
Typically here any network command performed using the usb_ether
interface would work, while using other gadgets would fail:
.. prompt:: bash
:prompts: =>
fastboot usb 0
.. code-block:: text
=> fastboot usb 0
All UDC in use (1 available), use the unbind command
g_dnl_register: failed!, error: -19
exit not allowed from main input shell.
All UDC in use (1 available), use the unbind command
g_dnl_register: failed!, error: -19
exit not allowed from main input shell.
As hinted by the primary error message, the only controller available
(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
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
first USB device controller, the fastboot gadget will now be able to
bind with it:
.. prompt:: bash
:prompts: =>
dm tree
.. code-block:: text
=> dm tree
Class Index Probed Driver Name
-----------------------------------------------------------
[...]
misc 0 [ + ] ti-musb-wrapper | |-- usb@47400000
usb 0 [ ] ti-musb-peripheral | | |-- usb@47401000
usb 0 [ ] ti-musb-host | | `-- usb@47401800
Class Index Probed Driver Name
-----------------------------------------------------------
[...]
misc 0 [ + ] ti-musb-wrapper | |-- usb@47400000
usb 0 [ ] ti-musb-peripheral | | |-- usb@47401000
usb 0 [ ] ti-musb-host | | `-- usb@47401800

188
doc/board/ti/am43xx_evm.rst Normal file
View 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
View 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.

3
doc/board/ti/index.rst
View file

@ -7,4 +7,7 @@ Texas Instruments
:maxdepth: 2
am335x_evm
am43xx_evm
dra7xx_evm
ks2_evm
k3

306
doc/board/ti/ks2_evm.rst Normal file
View 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