summaryrefslogtreecommitdiff
path: root/board
diff options
context:
space:
mode:
authorNeha Malcom Francis <n-francis@ti.com>2023-07-21 21:44:43 +0300
committerTom Rini <trini@konsulko.com>2023-07-22 02:36:59 +0300
commit1ee652ab2f356c8a775bc4878f32f26f29a4c941 (patch)
tree8d7bf1b245faf0d676ff9bbbdf838648f260bb4c /board
parent8db194d04612dd8431b42b8f76b12b0760bd264c (diff)
downloadu-boot-1ee652ab2f356c8a775bc4878f32f26f29a4c941.tar.xz
doc: board: ti: Update documentation for binman flow
Earlier documentation specified builds for generating bootloader images using an external TI repository k3-image-gen and core-secdev-k3. Modify this to using the binman flow so that user understands how to build the final boot images. Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Neha Malcom Francis <n-francis@ti.com>
Diffstat (limited to 'board')
-rw-r--r--board/ti/am65x/README350
1 files changed, 0 insertions, 350 deletions
diff --git a/board/ti/am65x/README b/board/ti/am65x/README
deleted file mode 100644
index 67081ce349..0000000000
--- a/board/ti/am65x/README
+++ /dev/null
@@ -1,350 +0,0 @@
-Introduction:
--------------
-The AM65x family of SoCs is the first device family from K3 Multicore
-SoC architecture, targeted for broad market and industrial control with
-aim to meet the complex processing needs of modern embedded products.
-
-The device is built over three domains, each containing specific processing
-cores, voltage domains and peripherals:
-1. Wake-up (WKUP) domain:
- - Device Management and Security Controller (DMSC)
-2. Microcontroller (MCU) domain:
- - Dual Core ARM Cortex-R5F processor
-3. MAIN domain:
- - Quad core 64-bit ARM Cortex-A53
-
-More info can be found in TRM: http://www.ti.com/lit/pdf/spruid7
-
-Boot Flow:
-----------
-On AM65x family devices, ROM supports boot only via MCU(R5). This means that
-bootloader has to run on R5 core. In order to meet this constraint, and for
-the following reasons the boot flow is designed as mentioned:
-1. Need to move away from R5 asap, so that we want to start *any*
-firmware on the r5 cores like.... autosar can be loaded to receive CAN
-response and other safety operations to be started. This operation is
-very time critical and is applicable for all automotive use cases.
-2. U-Boot on A53 should start other remotecores for various
-applications. This should happen before running Linux.
-3. In production boot flow, we might not like to use full u-boot,
-instead use Flacon boot flow to reduce boot time.
-
-+------------------------------------------------------------------------+
-| DMSC | R5 | A53 |
-+------------------------------------------------------------------------+
-| +--------+ | | |
-| | Reset | | | |
-| +--------+ | | |
-| : | | |
-| +--------+ | +-----------+ | |
-| | *ROM* |----------|-->| Reset rls | | |
-| +--------+ | +-----------+ | |
-| | | | : | |
-| | ROM | | : | |
-| |services| | : | |
-| | | | +-------------+ | |
-| | | | | *R5 ROM* | | |
-| | | | +-------------+ | |
-| | |<---------|---|Load and auth| | |
-| | | | | tiboot3.bin | | |
-| | | | +-------------+ | |
-| | | | : | |
-| | | | : | |
-| | | | : | |
-| | | | +-------------+ | |
-| | | | | *R5 SPL* | | |
-| | | | +-------------+ | |
-| | | | | Load | | |
-| | | | | sysfw.itb | | |
-| | Start | | +-------------+ | |
-| | System |<---------|---| Start | | |
-| |Firmware| | | SYSFW | | |
-| +--------+ | +-------------+ | |
-| : | | | | |
-| +---------+ | | Load | | |
-| | *SYSFW* | | | system | | |
-| +---------+ | | Config data | | |
-| | |<--------|---| | | |
-| | | | +-------------+ | |
-| | | | | | | |
-| | | | | DDR | | |
-| | | | | config | | |
-| | | | +-------------+ | |
-| | | | | | | |
-| | |<--------|---| Start A53 | | |
-| | | | | and Reset | | |
-| | | | +-------------+ | |
-| | | | | +-----------+ |
-| | |---------|-----------------------|---->| Reset rls | |
-| | | | | +-----------+ |
-| | DMSC | | | : |
-| |Services | | | +-----------+ |
-| | |<--------|-----------------------|---->|*ATF/OPTEE*| |
-| | | | | +-----------+ |
-| | | | | : |
-| | | | | +-----------+ |
-| | |<--------|-----------------------|---->| *A53 SPL* | |
-| | | | | +-----------+ |
-| | | | | | Load | |
-| | | | | | u-boot.img| |
-| | | | | +-----------+ |
-| | | | | : |
-| | | | | +-----------+ |
-| | |<--------|-----------------------|---->| *U-Boot* | |
-| | | | | +-----------+ |
-| | | | | | prompt | |
-| | | | | +-----------+ |
-| +---------+ | | |
-| | | |
-+------------------------------------------------------------------------+
-
-- Here DMSC acts as master and provides all the critical services. R5/A53
-requests DMSC to get these services done as shown in the above diagram.
-
-Sources:
---------
-1. SYSFW:
- Tree: git://git.ti.com/k3-image-gen/k3-image-gen.git
- Branch: master
-
-2. ATF:
- Tree: https://github.com/ARM-software/arm-trusted-firmware.git
- Branch: master
-
-3. OPTEE:
- Tree: https://github.com/OP-TEE/optee_os.git
- Branch: master
-
-4. U-Boot:
- Tree: http://git.denx.de/u-boot.git
- Branch: master
-
-Build procedure:
-----------------
-1. SYSFW:
-$ make CROSS_COMPILE=arm-linux-gnueabihf-
-
-2. ATF:
-$ make CROSS_COMPILE=aarch64-linux-gnu- ARCH=aarch64 PLAT=k3 TARGET_BOARD=generic SPD=opteed
-
-3. OPTEE:
-$ make PLATFORM=k3-am65x CFG_ARM64_core=y
-
-4. U-Boot:
-
-4.1. R5:
-$ make CROSS_COMPILE=arm-linux-gnueabihf- am65x_evm_r5_defconfig O=/tmp/r5
-$ make CROSS_COMPILE=arm-linux-gnueabihf- O=/tmp/r5
-
-4.2. A53:
-$ make CROSS_COMPILE=aarch64-linux-gnu- am65x_evm_a53_defconfig O=/tmp/a53
-$ make CROSS_COMPILE=aarch64-linux-gnu- ATF=<path to ATF dir>/build/k3/generic/release/bl31.bin TEE=<path to OPTEE OS dir>/out/arm-plat-k3/core/tee-pager_v2.bin O=/tmp/a53
-
-Target Images
---------------
-Copy the below images to an SD card and boot:
-- sysfw.itb from step 1
-- tiboot3.bin from step 4.1
-- tispl.bin, u-boot.img from 4.2
-
-Image formats:
---------------
-
-- tiboot3.bin:
- +-----------------------+
- | X.509 |
- | Certificate |
- | +-------------------+ |
- | | | |
- | | R5 | |
- | | u-boot-spl.bin | |
- | | | |
- | +-------------------+ |
- | | | |
- | | FIT header | |
- | | +---------------+ | |
- | | | | | |
- | | | DTB 1...N | | |
- | | +---------------+ | |
- | +-------------------+ |
- +-----------------------+
-
-- tispl.bin
- +-----------------------+
- | |
- | FIT HEADER |
- | +-------------------+ |
- | | | |
- | | A53 ATF | |
- | +-------------------+ |
- | | | |
- | | A53 OPTEE | |
- | +-------------------+ |
- | | | |
- | | A53 SPL | |
- | +-------------------+ |
- | | | |
- | | SPL DTB 1...N | |
- | +-------------------+ |
- +-----------------------+
-
-- sysfw.itb
- +-----------------------+
- | |
- | FIT HEADER |
- | +-------------------+ |
- | | | |
- | | sysfw.bin | |
- | +-------------------+ |
- | | | |
- | | board config | |
- | +-------------------+ |
- | | | |
- | | PM config | |
- | +-------------------+ |
- | | | |
- | | RM config | |
- | +-------------------+ |
- | | | |
- | | Secure config | |
- | +-------------------+ |
- +-----------------------+
-
-eMMC:
------
-ROM supports booting from eMMC from boot0 partition offset 0x0
-
-Flashing images to eMMC:
-
-The following commands can be used to download tiboot3.bin, tispl.bin,
-u-boot.img, and sysfw.itb from an SD card and write them to the eMMC boot0
-partition at respective addresses.
-
-=> mmc dev 0 1
-=> fatload mmc 1 ${loadaddr} tiboot3.bin
-=> mmc write ${loadaddr} 0x0 0x400
-=> fatload mmc 1 ${loadaddr} tispl.bin
-=> mmc write ${loadaddr} 0x400 0x1000
-=> fatload mmc 1 ${loadaddr} u-boot.img
-=> mmc write ${loadaddr} 0x1400 0x2000
-=> fatload mmc 1 ${loadaddr} sysfw.itb
-=> mmc write ${loadaddr} 0x3600 0x800
-
-To give the ROM access to the boot partition, the following commands must be
-used for the first time:
-=> mmc partconf 0 1 1 1
-=> mmc bootbus 0 1 0 0
-
-To create a software partition for the rootfs, the following command can be
-used:
-=> gpt write mmc 0 ${partitions}
-
-eMMC layout:
-
- boot0 partition (8 MB) user partition
- 0x0+----------------------------------+ 0x0+-------------------------+
- | tiboot3.bin (512 KB) | | |
- 0x400+----------------------------------+ | |
- | tispl.bin (2 MB) | | |
-0x1400+----------------------------------+ | rootfs |
- | u-boot.img (4 MB) | | |
-0x3400+----------------------------------+ | |
- | environment (128 KB) | | |
-0x3500+----------------------------------+ | |
- | backup environment (128 KB) | | |
-0x3600+----------------------------------+ | |
- | sysfw (1 MB) | | |
-0x3E00+----------------------------------+ +-------------------------+
-
-Kernel image and DT are expected to be present in the /boot folder of rootfs.
-To boot kernel from eMMC, use the following commands:
-=> setenv mmcdev 0
-=> setenv bootpart 0
-=> boot
-
-OSPI:
------
-ROM supports booting from OSPI from offset 0x0.
-
-Flashing images to OSPI:
-
-Below commands can be used to download tiboot3.bin, tispl.bin, u-boot.img,
-and sysfw.itb over tftp and then flash those to OSPI at their respective
-addresses.
-
-=> sf probe
-=> tftp ${loadaddr} tiboot3.bin
-=> sf update $loadaddr 0x0 $filesize
-=> tftp ${loadaddr} tispl.bin
-=> sf update $loadaddr 0x80000 $filesize
-=> tftp ${loadaddr} u-boot.img
-=> sf update $loadaddr 0x280000 $filesize
-=> tftp ${loadaddr} sysfw.itb
-=> sf update $loadaddr 0x6C0000 $filesize
-
-Flash layout for OSPI:
-
- 0x0 +----------------------------+
- | ospi.tiboot3(512K) |
- | |
- 0x80000 +----------------------------+
- | ospi.tispl(2M) |
- | |
- 0x280000 +----------------------------+
- | ospi.u-boot(4M) |
- | |
- 0x680000 +----------------------------+
- | ospi.env(128K) |
- | |
- 0x6A0000 +----------------------------+
- | ospi.env.backup (128K) |
- | |
- 0x6C0000 +----------------------------+
- | ospi.sysfw(1M) |
- | |
- 0x7C0000 +----------------------------+
- | padding (256k) |
- 0x800000 +----------------------------+
- | ospi.rootfs(UBIFS) |
- | |
- +----------------------------+
-
-Kernel Image and DT are expected to be present in the /boot folder of UBIFS
-ospi.rootfs just like in SD card case. U-Boot looks for UBI volume named
-"rootfs" for rootfs.
-
-To boot kernel from OSPI, at the U-Boot prompt:
-=> setenv boot ubi
-=> boot
-
-UART:
------
-ROM supports booting from MCU_UART0 via X-Modem protocol. The entire UART-based
-boot process up to U-Boot (proper) prompt goes through different stages and uses
-different UART peripherals as follows:
-
- WHO | Loading WHAT | HW Module | Protocol
-----------+---------------+-------------+------------
-Boot ROM | tiboot3.bin | MCU_UART0 | X-Modem(*)
-R5 SPL | sysfw.itb | MCU_UART0 | Y-Modem(*)
-R5 SPL | tispl.bin | MAIN_UART0 | Y-Modem
-A53 SPL | u-boot.img | MAIN_UART0 | Y-Modem
-
-(*) Note that in addition to X/Y-Modem related protocol timeouts the DMSC
- watchdog timeout of 3min (typ.) needs to be observed until System Firmware
- is fully loaded (from sysfw.itb) and started.
-
-Example bash script sequence for running on a Linux host PC feeding all boot
-artifacts needed to the device:
-
-MCU_DEV=/dev/ttyUSB1
-MAIN_DEV=/dev/ttyUSB0
-
-stty -F $MCU_DEV 115200 cs8 -cstopb -parenb
-stty -F $MAIN_DEV 115200 cs8 -cstopb -parenb
-
-sb --xmodem tiboot3.bin > $MCU_DEV < $MCU_DEV
-sb --ymodem sysfw.itb > $MCU_DEV < $MCU_DEV
-sb --ymodem tispl.bin > $MAIN_DEV < $MAIN_DEV
-sleep 1
-sb --xmodem u-boot.img > $MAIN_DEV < $MAIN_DEV