mirror of
https://github.com/AsahiLinux/u-boot
synced 2024-11-24 21:54:01 +00:00
Documentation:
* hikey960: update link URLs * j7200_evm: Fix OPTEE platform name * ti: fix style of examples * fix typos -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEEK7wKXt3/btL6/yA+hO4vgnE3U0sFAmVOz18ACgkQhO4vgnE3 U0vcTw/+IiJgluko4+eeyv4IDw9Irc2w3HRq8ZgrNsyx0gdSsnvo/rRfyB9uggfQ AJSXDkEHxyWYmta0kz79Dy6SwM9+ez1rhjr4Hz5MrBWPgV4aNqbpY7TlTUjmtU2O +oVc+dDpIDfo5Pje+q4yl+YmsQ/YXl45IL0fVJ0FVVZg5oIhNsMo+u1d/umH0+iU 1rIYBvx1ncODpJB/XcqYQbPYQ3VH5uaSe/x4FVYycx/RGvWZQvohgtE2drNiBE1l wAMswDD0PyLWUjAtZwFyzN8VpCcXIGUn/5pUkJ4XaZaKci65beRnEFi0mZDuo+H7 nMY7VxzDTXQTXvQCkZMuU6Uqn5YU/gop5T0ew2MbxJI1SRMYXecTtS+oo0Btd2oH fJFrX9+OBQaZF7Qdii6EreuSAz3nFgWF3p7n2ffGgImzJCpBCznIjXr7Q1iOO30o OAD/JxzFgHeQdaOHxlOUIRqnAQNOQ+svtehga9IKi3B/uIuF4EgHxYb8dNMvVepd ZIVX6fA6MNHpfk8e/lzpQSn7sj875perxUIU975ukrAskM2+6hqbOzxQ2v9uHW9n HXWpu1hLOBwx2lU6jYv2CDihQy3mEkbRjVKwNw4vESB1m3YflswfwYbOI+0aGW8e V0jkaVGt78uGYeLl8BHtD/ZSWrrdYeF3XRk2cpxI67i7Rp+Ld8o= =nXZy -----END PGP SIGNATURE----- Merge tag 'doc-2024-01-rc3' of https://source.denx.de/u-boot/custodians/u-boot-efi Documentation: * hikey960: update link URLs * j7200_evm: Fix OPTEE platform name * ti: fix style of examples * fix typos
This commit is contained in:
Tom Rini
commit
17e9db18f1
49 changed files with 268 additions and 271 deletions
|
|
@ -26,12 +26,12 @@ First get all the sources
|
|||
> git clone https://github.com/ARM-software/arm-trusted-firmware
|
||||
> git clone https://github.com/96boards-hikey/OpenPlatformPkg -b testing/hikey960_v1.3.4
|
||||
> git clone https://github.com/96boards-hikey/l-loader -b testing/hikey960_v1.2
|
||||
> wget http://snapshots.linaro.org/96boards/reference-platform/components/uefi-staging/latest/hikey960/release/config
|
||||
> wget http://snapshots.linaro.org/96boards/reference-platform/components/uefi-staging/latest/hikey960/release/hisi-sec_usb_xloader.img
|
||||
> wget http://snapshots.linaro.org/96boards/reference-platform/components/uefi-staging/latest/hikey960/release/hisi-sec_uce_boot.img
|
||||
> wget http://snapshots.linaro.org/96boards/reference-platform/components/uefi-staging/latest/hikey960/release/sec_xloader.img
|
||||
> wget http://snapshots.linaro.org/96boards/reference-platform/components/uefi-staging/latest/hikey960/release/recovery.bin
|
||||
> wget http://snapshots.linaro.org/96boards/reference-platform/components/uefi-staging/latest/hikey960/release/hikey_idt
|
||||
> wget http://snapshots.linaro.org/reference-platform/components/uefi-staging/123/hikey960/release/config
|
||||
> wget http://snapshots.linaro.org/reference-platform/components/uefi-staging/123/hikey960/release/hisi-sec_usb_xloader.img
|
||||
> wget http://snapshots.linaro.org/reference-platform/components/uefi-staging/123/hikey960/release/hisi-sec_uce_boot.img
|
||||
> wget http://snapshots.linaro.org/reference-platform/components/uefi-staging/123/hikey960/release/hisi-sec_xloader.img
|
||||
> wget http://snapshots.linaro.org/reference-platform/components/uefi-staging/123/hikey960/release/recovery.bin
|
||||
> wget http://snapshots.linaro.org/reference-platform/components/uefi-staging/123/hikey960/release/hikey_idt
|
||||
|
||||
Get the SCP_BL2 lpm3.img binary. It is shipped as part of the UEFI source.
|
||||
The latest version can be obtained from the OpenPlatformPkg repo.
|
||||
|
|
@ -126,7 +126,7 @@ following command
|
|||
Now, the images can be flashed using fastboot:
|
||||
|
||||
> sudo fastboot flash ptable ~/hikey960/bin/prm_ptable.img
|
||||
> sudo fastboot flash xloader ~/hikey960/bin/sec_xloader.img
|
||||
> sudo fastboot flash xloader ~/hikey960/bin/hisi-sec_xloader.img
|
||||
> sudo fastboot flash fastboot ~/hikey960/bin/l-loader.bin
|
||||
> sudo fastboot flash fip ~/hikey960/bin/fip.bin
|
||||
|
||||
|
|
|
|||
|
|
@ -40,7 +40,7 @@ The U-Boot FF-A support provides the following parts:
|
|||
- Sandbox FF-A test cases.
|
||||
|
||||
FF-A and SMC specifications
|
||||
-------------------------------------------
|
||||
---------------------------
|
||||
|
||||
The current implementation of the U-Boot FF-A support relies on
|
||||
`FF-A v1.0 specification`_ and uses SMC32 calling convention which
|
||||
|
|
@ -56,12 +56,12 @@ Hypervisors are supported if they are configured to trap SMC calls.
|
|||
The FF-A support uses 64-bit registers as per `SMC Calling Convention v1.2 specification`_.
|
||||
|
||||
Supported hardware
|
||||
--------------------------------
|
||||
------------------
|
||||
|
||||
Aarch64 plaforms
|
||||
|
||||
Configuration
|
||||
----------------------
|
||||
-------------
|
||||
|
||||
CONFIG_ARM_FFA_TRANSPORT
|
||||
Enables the FF-A support. Turn this on if you want to use FF-A
|
||||
|
|
@ -70,7 +70,7 @@ CONFIG_ARM_FFA_TRANSPORT
|
|||
When using sandbox, the sandbox FF-A emulator and FF-A sandbox driver will be used.
|
||||
|
||||
FF-A ABIs under the hood
|
||||
---------------------------------------
|
||||
------------------------
|
||||
|
||||
Invoking an FF-A ABI involves providing to the secure world/hypervisor the
|
||||
expected arguments from the ABI.
|
||||
|
|
@ -89,7 +89,7 @@ The driver reads the response and processes it accordingly.
|
|||
This methodology applies to all the FF-A ABIs.
|
||||
|
||||
FF-A bus discovery on Arm 64-bit platforms
|
||||
---------------------------------------------
|
||||
------------------------------------------
|
||||
|
||||
When CONFIG_ARM_FFA_TRANSPORT is enabled, the FF-A bus is considered as
|
||||
an architecture feature and discovered using ARM_SMCCC_FEATURES mechanism.
|
||||
|
|
@ -136,7 +136,7 @@ When one of the above actions fails, probing fails and the driver stays not acti
|
|||
and can be probed again if needed.
|
||||
|
||||
Requirements for clients
|
||||
-------------------------------------
|
||||
------------------------
|
||||
|
||||
When using the FF-A bus with EFI, clients must query the SPs they are looking for
|
||||
during EFI boot-time mode using the service UUID.
|
||||
|
|
@ -159,13 +159,13 @@ the 32-bit or 64-bit version of FFA_MSG_SEND_DIRECT_{REQ, RESP}.
|
|||
The calling convention between U-Boot and the secure world stays the same: SMC32.
|
||||
|
||||
Requirements for user drivers
|
||||
-------------------------------------
|
||||
-----------------------------
|
||||
|
||||
Users who want to implement their custom FF-A device driver while reusing the FF-A Uclass can do so
|
||||
by implementing their own invoke_ffa_fn() in the user driver.
|
||||
|
||||
The bus driver layer
|
||||
------------------------------
|
||||
--------------------
|
||||
|
||||
FF-A support comes on top of the SMCCC layer and is implemented by the FF-A Uclass drivers/firmware/arm-ffa/arm-ffa-uclass.c
|
||||
|
||||
|
|
@ -210,7 +210,7 @@ The following features are provided:
|
|||
- FF-A bus can be compiled and used without EFI
|
||||
|
||||
Relationship between the sandbox emulator and the FF-A device
|
||||
---------------------------------------------------------------
|
||||
-------------------------------------------------------------
|
||||
|
||||
::
|
||||
|
||||
|
|
@ -222,7 +222,7 @@ Relationship between the sandbox emulator and the FF-A device
|
|||
ffa 0 [ ] sandbox_arm_ffa `-- sandbox-arm-ffa
|
||||
|
||||
The armffa command
|
||||
-----------------------------------
|
||||
------------------
|
||||
|
||||
armffa is a command showcasing how to use the FF-A bus and how to invoke the driver operations.
|
||||
|
||||
|
|
|
|||
|
|
@ -1,7 +1,7 @@
|
|||
.. SPDX-License-Identifier: GPL-2.0+
|
||||
|
||||
AE350
|
||||
======
|
||||
=====
|
||||
|
||||
AE350 is the mainline SoC produced by Andes Technology using AndesV5 CPU core
|
||||
based on RISC-V architecture.
|
||||
|
|
|
|||
|
|
@ -20,7 +20,7 @@ Though, one can enter ADFU mode and flash debian image(from host machine) where
|
|||
getting into u-boot prompt is easy.
|
||||
|
||||
Enter ADFU Mode
|
||||
----------------
|
||||
---------------
|
||||
|
||||
Before write the firmware, let the development board entering the ADFU mode: insert
|
||||
one end of the USB cable to the PC, press and hold the ADFU button, and then connect
|
||||
|
|
@ -28,7 +28,7 @@ the other end of the USB cable to the Mini USB port of the development board, re
|
|||
the ADFU button, after connecting it will enter the ADFU mode.
|
||||
|
||||
Check whether entered ADFU Mode
|
||||
--------------------------------
|
||||
-------------------------------
|
||||
|
||||
The user needs to run the following command on the PC side to check if the ADFU
|
||||
device is detected. ID realted to "Actions Semiconductor Co., Ltd" means that
|
||||
|
|
|
|||
|
|
@ -2,7 +2,7 @@
|
|||
.. Copyright (C) 2020 Amit Singh Tomar <amittomer25@gmail.com>
|
||||
|
||||
Actions
|
||||
========
|
||||
=======
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 2
|
||||
|
|
|
|||
|
|
@ -1,7 +1,7 @@
|
|||
.. SPDX-License-Identifier: GPL-2.0
|
||||
|
||||
Arm Ltd
|
||||
=============
|
||||
=======
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 2
|
||||
|
|
|
|||
|
|
@ -1,7 +1,7 @@
|
|||
.. SPDX-License-Identifier: GPL-2.0+
|
||||
|
||||
Mediatek
|
||||
=========
|
||||
========
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 2
|
||||
|
|
|
|||
|
|
@ -36,7 +36,7 @@ Get the ddr firmware
|
|||
$ cp firmware-imx-8.9/firmware/ddr/synopsys/lpddr4*.bin $(builddir)
|
||||
|
||||
Build U-Boot for sd card
|
||||
--------------------------
|
||||
------------------------
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
|
|
@ -54,8 +54,8 @@ Boot
|
|||
----
|
||||
Set Boot switch to SD boot
|
||||
|
||||
Build U-Boot for qspi flash card
|
||||
------------------------------------
|
||||
Build U-Boot for qspi flash card
|
||||
--------------------------------
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
|
|
@ -81,7 +81,8 @@ From sd card to memory
|
|||
$ sf write $loadaddr 0x00 <size_of_flash.bin_in_hex>
|
||||
|
||||
Boot from QSPI Flash
|
||||
-----------------------
|
||||
--------------------
|
||||
|
||||
Set Boot Switch to QSPI Flash
|
||||
|
||||
Pin configuration for imx8mm_revC evk to boot from qspi flash
|
||||
|
|
|
|||
|
|
@ -54,7 +54,7 @@ LS1046ARDB board Overview
|
|||
- ARM JTAG support
|
||||
|
||||
Memory map from core's view
|
||||
----------------------------
|
||||
---------------------------
|
||||
|
||||
================== ================== ================ =====
|
||||
Start Address End Address Description Size
|
||||
|
|
|
|||
|
|
@ -4,7 +4,7 @@ mx6ul_14x14_evk
|
|||
===============
|
||||
|
||||
How to use U-Boot on Freescale MX6UL 14x14 EVK
|
||||
-----------------------------------------------
|
||||
----------------------------------------------
|
||||
|
||||
- Build U-Boot for MX6UL 14x14 EVK:
|
||||
|
||||
|
|
|
|||
|
|
@ -11,14 +11,14 @@ OpenPiton has been verified in both ASIC and multiple Xilinx FPGA prototypes
|
|||
running full-stack Debian linux.
|
||||
|
||||
RISC-V Standard Bootflow
|
||||
-------------------------
|
||||
------------------------
|
||||
|
||||
Currently, OpenPiton implements RISC-V standard bootflow in the following steps
|
||||
mover.S -> u-boot-spl -> opensbi -> u-boot -> Linux
|
||||
This board supports S-mode u-boot as well as M-mode SPL
|
||||
|
||||
Building OpenPition
|
||||
---------------------
|
||||
-------------------
|
||||
|
||||
If you'd like to build OpenPiton, please go to OpenPiton github repo
|
||||
(at https://github.com/PrincetonUniversity/openpiton) to build from the latest
|
||||
|
|
|
|||
|
|
@ -1,7 +1,7 @@
|
|||
.. SPDX-License-Identifier: GPL-2.0+
|
||||
|
||||
Librem5
|
||||
==========
|
||||
=======
|
||||
|
||||
U-Boot for the Purism Librem5 phone
|
||||
|
||||
|
|
|
|||
|
|
@ -2,10 +2,11 @@
|
|||
.. sectionauthor:: Dzmitry Sankouski <dsankouski@gmail.com>
|
||||
|
||||
Snapdragon 845
|
||||
================
|
||||
==============
|
||||
|
||||
About this
|
||||
----------
|
||||
|
||||
This document describes the information about Qualcomm Snapdragon 845
|
||||
supported boards and it's usage steps.
|
||||
|
||||
|
|
@ -17,8 +18,10 @@ Qualcomm's UEFI-based ABL (Android) Bootloader.
|
|||
|
||||
Installation
|
||||
------------
|
||||
|
||||
Build
|
||||
^^^^^
|
||||
|
||||
Setup ``CROSS_COMPILE`` for aarch64 and build U-Boot for your board::
|
||||
|
||||
$ export CROSS_COMPILE=<aarch64 toolchain prefix>
|
||||
|
|
@ -29,10 +32,12 @@ This will build ``u-boot.bin`` in the configured output directory.
|
|||
|
||||
Generate FIT image
|
||||
^^^^^^^^^^^^^^^^^^
|
||||
|
||||
See doc/uImage.FIT for more details
|
||||
|
||||
Pack android boot image
|
||||
^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
We'll assemble android boot image with ``u-boot.bin`` instead of linux kernel,
|
||||
and FIT image instead of ``initramfs``. Android bootloader expect gzipped kernel
|
||||
with appended dtb, so let's mimic linux to satisfy stock bootloader.
|
||||
|
|
|
|||
|
|
@ -1,7 +1,7 @@
|
|||
.. SPDX-License-Identifier: GPL-2.0+
|
||||
|
||||
Samsung
|
||||
========
|
||||
=======
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 2
|
||||
|
|
|
|||
|
|
@ -2,7 +2,7 @@
|
|||
.. sectionauthor:: Patrick Delaunay <patrick.delaunay@foss.st.com>
|
||||
|
||||
U-Boot device tree bindings
|
||||
----------------------------
|
||||
---------------------------
|
||||
|
||||
The U-Boot specific bindings are defined in the U-Boot directory:
|
||||
doc/device-tree-bindings
|
||||
|
|
|
|||
|
|
@ -2,7 +2,7 @@
|
|||
.. sectionauthor:: Patrice Chotard <patrice.chotardy@foss.st.com>
|
||||
|
||||
STM32 MCU boards
|
||||
=================
|
||||
================
|
||||
|
||||
This is a quick instruction for setup STM32 MCU boards.
|
||||
|
||||
|
|
|
|||
|
|
@ -4,7 +4,8 @@ StarFive VisionFive2
|
|||
====================
|
||||
|
||||
JH7110 RISC-V SoC
|
||||
---------------------
|
||||
-----------------
|
||||
|
||||
The JH7110 is 4+1 64-bit RISC-V SoC from StarFive.
|
||||
|
||||
The StarFive VisionFive2 development platform is based on JH7110 and capable
|
||||
|
|
|
|||
|
|
@ -1,7 +1,7 @@
|
|||
.. SPDX-License-Identifier: GPL-2.0+
|
||||
|
||||
T-HEAD
|
||||
========
|
||||
======
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 1
|
||||
|
|
|
|||
|
|
@ -84,8 +84,7 @@ bootable image was not created.
|
|||
|
||||
Within the SECDEV package exists an image creation script:
|
||||
|
||||
.. prompt:: bash
|
||||
:prompts: $
|
||||
.. prompt:: bash $
|
||||
|
||||
${TI_SECURE_DEV_PKG}/scripts/create-boot-image.sh
|
||||
|
||||
|
|
@ -97,8 +96,7 @@ 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: $
|
||||
.. prompt:: bash $
|
||||
|
||||
create-boot-image.sh \
|
||||
<IMAGE_FLAG> <INPUT_FILE> <OUTPUT_FILE> <SPL_LOAD_ADDR>
|
||||
|
|
@ -184,8 +182,7 @@ 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: $
|
||||
.. prompt:: bash $
|
||||
|
||||
${TI_SECURE_DEV_PKG}/scripts/secure-binary-image.sh
|
||||
|
||||
|
|
@ -206,8 +203,7 @@ only accessible when the ARM core is operating in the secure mode).
|
|||
Invoking the secure-binary-image script for Secure Devices
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
.. prompt:: bash
|
||||
:prompts: $
|
||||
.. prompt:: bash $
|
||||
|
||||
secure-binary-image.sh <INPUT_FILE> <OUTPUT_FILE>
|
||||
|
||||
|
|
@ -247,8 +243,7 @@ into memory, then written to NAND.
|
|||
|
||||
2. Flashing NAND via MMC/SD
|
||||
|
||||
.. prompt:: bash
|
||||
:prompts: =>
|
||||
.. prompt:: bash =>
|
||||
|
||||
# select BOOTSEL to MMC/SD boot and boot from MMC/SD card
|
||||
mmc rescan
|
||||
|
|
@ -334,8 +329,7 @@ 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.
|
||||
|
||||
.. prompt:: bash
|
||||
:prompts: =>
|
||||
.. prompt:: bash =>
|
||||
|
||||
# Ensure we are able to talk with this mmc device
|
||||
mmc rescan
|
||||
|
|
@ -366,8 +360,7 @@ 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:
|
||||
|
||||
.. prompt:: bash
|
||||
:prompts: =>
|
||||
.. prompt:: bash =>
|
||||
|
||||
mmc rescan
|
||||
# Load kernel and device tree into memory, perform export
|
||||
|
|
@ -386,8 +379,7 @@ This will print a number of lines and then end with something like:
|
|||
|
||||
So then you:
|
||||
|
||||
.. prompt:: bash
|
||||
:prompts: =>
|
||||
.. prompt:: bash =>
|
||||
|
||||
fatwrite mmc 0:1 0x80f80000 args 8928
|
||||
|
||||
|
|
@ -400,8 +392,7 @@ 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:
|
||||
|
||||
.. prompt:: bash
|
||||
:prompts: =>
|
||||
.. prompt:: bash =>
|
||||
|
||||
nand read ${loadaddr} kernel
|
||||
load nand rootfs ${fdtaddr} /boot/am335x-evm.dtb
|
||||
|
|
@ -425,8 +416,7 @@ 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: =>
|
||||
.. prompt:: bash =>
|
||||
|
||||
dm tree
|
||||
|
||||
|
|
@ -444,8 +434,7 @@ the command line:
|
|||
Typically here any network command performed using the usb_ether
|
||||
interface would work, while using other gadgets would fail:
|
||||
|
||||
.. prompt:: bash
|
||||
:prompts: =>
|
||||
.. prompt:: bash =>
|
||||
|
||||
fastboot usb 0
|
||||
|
||||
|
|
@ -462,8 +451,7 @@ 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:
|
||||
|
||||
.. prompt:: bash
|
||||
:prompts: =>
|
||||
.. prompt:: bash =>
|
||||
|
||||
unbind ethernet 1
|
||||
|
||||
|
|
@ -471,8 +459,7 @@ 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: =>
|
||||
.. prompt:: bash =>
|
||||
|
||||
dm tree
|
||||
|
||||
|
|
|
|||
|
|
@ -55,22 +55,22 @@ Set the variables corresponding to this platform:
|
|||
.. include:: k3.rst
|
||||
:start-after: .. k3_rst_include_start_common_env_vars_defn
|
||||
:end-before: .. k3_rst_include_end_common_env_vars_defn
|
||||
.. code-block:: bash
|
||||
.. prompt:: bash $
|
||||
|
||||
$ export UBOOT_CFG_CORTEXR="am62x_evm_r5_defconfig beagleplay_r5.config"
|
||||
$ export UBOOT_CFG_CORTEXA="am62x_evm_a53_defconfig beagleplay_a53.config"
|
||||
$ export TFA_BOARD=lite
|
||||
$ # we dont use any extra TFA parameters
|
||||
$ unset TFA_EXTRA_ARGS
|
||||
$ export OPTEE_PLATFORM=k3-am62x
|
||||
$ export OPTEE_EXTRA_ARGS="CFG_WITH_SOFTWARE_PRNG=y"
|
||||
export UBOOT_CFG_CORTEXR="am62x_evm_r5_defconfig beagleplay_r5.config"
|
||||
export UBOOT_CFG_CORTEXA="am62x_evm_a53_defconfig beagleplay_a53.config"
|
||||
export TFA_BOARD=lite
|
||||
# we dont use any extra TFA parameters
|
||||
unset TFA_EXTRA_ARGS
|
||||
export OPTEE_PLATFORM=k3-am62x
|
||||
export OPTEE_EXTRA_ARGS="CFG_WITH_SOFTWARE_PRNG=y"
|
||||
|
||||
.. include:: am62x_sk.rst
|
||||
:start-after: .. am62x_evm_rst_include_start_build_steps
|
||||
:end-before: .. am62x_evm_rst_include_end_build_steps
|
||||
|
||||
Target Images
|
||||
--------------
|
||||
-------------
|
||||
Copy the below images to an SD card and boot:
|
||||
|
||||
* tiboot3-am62x-gp-evm.bin from R5 build as tiboot3.bin
|
||||
|
|
@ -109,7 +109,7 @@ There are multiple storage media options on BeaglePlay, but primarily:
|
|||
depends on the SD card quality.
|
||||
|
||||
Flash to uSD card or how to deal with "bricked" Board
|
||||
--------------------------------------------------------
|
||||
-----------------------------------------------------
|
||||
|
||||
When deploying or working on Linux, it's common to use the onboard
|
||||
eMMC. However, avoiding the eMMC and using the uSD card is safer when
|
||||
|
|
@ -174,24 +174,24 @@ boot1 partition depends on A/B update requirements.
|
|||
|
||||
The following are the steps from Linux shell to program eMMC:
|
||||
|
||||
.. code-block:: bash
|
||||
.. prompt:: bash #
|
||||
|
||||
# # Enable Boot0 boot
|
||||
# mmc bootpart enable 1 2 /dev/mmcblk0
|
||||
# mmc bootbus set single_backward x1 x8 /dev/mmcblk0
|
||||
# mmc hwreset enable /dev/mmcblk0
|
||||
# Enable Boot0 boot
|
||||
mmc bootpart enable 1 2 /dev/mmcblk0
|
||||
mmc bootbus set single_backward x1 x8 /dev/mmcblk0
|
||||
mmc hwreset enable /dev/mmcblk0
|
||||
|
||||
# # Clear eMMC boot0
|
||||
# echo '0' >> /sys/class/block/mmcblk0boot0/force_ro
|
||||
# dd if=/dev/zero of=/dev/mmcblk0boot0 count=32 bs=128k
|
||||
# # Write tiboot3.bin
|
||||
# dd if=tiboot3.bin of=/dev/mmcblk0boot0 bs=128k
|
||||
# Clear eMMC boot0
|
||||
echo '0' >> /sys/class/block/mmcblk0boot0/force_ro
|
||||
dd if=/dev/zero of=/dev/mmcblk0boot0 count=32 bs=128k
|
||||
# Write tiboot3.bin
|
||||
dd if=tiboot3.bin of=/dev/mmcblk0boot0 bs=128k
|
||||
|
||||
# # Copy the rest of the boot binaries
|
||||
# mount /dev/mmcblk0p1 /boot/firmware
|
||||
# cp tispl.bin /boot/firmware
|
||||
# cp u-boot.img /boot/firmware
|
||||
# sync
|
||||
# Copy the rest of the boot binaries
|
||||
mount /dev/mmcblk0p1 /boot/firmware
|
||||
cp tispl.bin /boot/firmware
|
||||
cp u-boot.img /boot/firmware
|
||||
sync
|
||||
|
||||
.. warning ::
|
||||
|
||||
|
|
|
|||
|
|
@ -2,7 +2,7 @@
|
|||
.. sectionauthor:: Vignesh Raghavendra <vigneshr@ti.com>
|
||||
|
||||
AM62 Platforms
|
||||
===============
|
||||
==============
|
||||
|
||||
Introduction:
|
||||
-------------
|
||||
|
|
@ -76,15 +76,15 @@ Set the variables corresponding to this platform:
|
|||
.. include:: ../ti/k3.rst
|
||||
:start-after: .. k3_rst_include_start_common_env_vars_defn
|
||||
:end-before: .. k3_rst_include_end_common_env_vars_defn
|
||||
.. code-block:: bash
|
||||
.. prompt:: bash $
|
||||
|
||||
$ export UBOOT_CFG_CORTEXR=am62x_evm_r5_defconfig
|
||||
$ export UBOOT_CFG_CORTEXA=am62x_evm_a53_defconfig
|
||||
$ export TFA_BOARD=lite
|
||||
$ # we dont use any extra TFA parameters
|
||||
$ unset TFA_EXTRA_ARGS
|
||||
$ export OPTEE_PLATFORM=k3-am62x
|
||||
$ export OPTEE_EXTRA_ARGS="CFG_WITH_SOFTWARE_PRNG=y"
|
||||
export UBOOT_CFG_CORTEXR=am62x_evm_r5_defconfig
|
||||
export UBOOT_CFG_CORTEXA=am62x_evm_a53_defconfig
|
||||
export TFA_BOARD=lite
|
||||
# we dont use any extra TFA parameters
|
||||
unset TFA_EXTRA_ARGS
|
||||
export OPTEE_PLATFORM=k3-am62x
|
||||
export OPTEE_EXTRA_ARGS="CFG_WITH_SOFTWARE_PRNG=y"
|
||||
|
||||
.. am62x_evm_rst_include_start_build_steps
|
||||
|
||||
|
|
@ -117,7 +117,8 @@ Set the variables corresponding to this platform:
|
|||
.. am62x_evm_rst_include_end_build_steps
|
||||
|
||||
Target Images
|
||||
--------------
|
||||
-------------
|
||||
|
||||
In order to boot we need tiboot3.bin, tispl.bin and u-boot.img. Each SoC
|
||||
variant (GP, HS-FS, HS-SE) requires a different source for these files.
|
||||
|
||||
|
|
@ -270,6 +271,6 @@ detailed setup information.
|
|||
|
||||
To start OpenOCD and connect to the board
|
||||
|
||||
.. code-block:: bash
|
||||
.. prompt:: bash $
|
||||
|
||||
openocd -f board/ti_am625evm.cfg
|
||||
|
|
|
|||
|
|
@ -65,16 +65,16 @@ Set the variables corresponding to this platform:
|
|||
.. include:: k3.rst
|
||||
:start-after: .. k3_rst_include_start_common_env_vars_defn
|
||||
:end-before: .. k3_rst_include_end_common_env_vars_defn
|
||||
.. code-block:: bash
|
||||
.. prompt:: bash $
|
||||
|
||||
$ export UBOOT_CFG_CORTEXR=am64x_evm_r5_defconfig
|
||||
$ export UBOOT_CFG_CORTEXA=am64x_evm_a53_defconfig
|
||||
$ export TFA_BOARD=lite
|
||||
$ # we dont use any extra TFA parameters
|
||||
$ unset TFA_EXTRA_ARGS
|
||||
$ export OPTEE_PLATFORM=k3-am64x
|
||||
$ # we dont use any extra TFA parameters
|
||||
$ unset OPTEE_EXTRA_ARGS
|
||||
export UBOOT_CFG_CORTEXR=am64x_evm_r5_defconfig
|
||||
export UBOOT_CFG_CORTEXA=am64x_evm_a53_defconfig
|
||||
export TFA_BOARD=lite
|
||||
# we dont use any extra TFA parameters
|
||||
unset TFA_EXTRA_ARGS
|
||||
export OPTEE_PLATFORM=k3-am64x
|
||||
# we dont use any extra TFA parameters
|
||||
unset OPTEE_EXTRA_ARGS
|
||||
|
||||
.. am64x_evm_rst_include_start_build_steps
|
||||
|
||||
|
|
@ -107,7 +107,8 @@ Set the variables corresponding to this platform:
|
|||
.. am64x_evm_rst_include_end_build_steps
|
||||
|
||||
Target Images
|
||||
--------------
|
||||
-------------
|
||||
|
||||
In order to boot we need tiboot3.bin, tispl.bin and u-boot.img. Each SoC
|
||||
variant (GP, HS-FS, HS-SE) requires a different source for these files.
|
||||
|
||||
|
|
|
|||
|
|
@ -75,16 +75,16 @@ Set the variables corresponding to this platform:
|
|||
.. include:: k3.rst
|
||||
:start-after: .. k3_rst_include_start_common_env_vars_defn
|
||||
:end-before: .. k3_rst_include_end_common_env_vars_defn
|
||||
.. code-block:: bash
|
||||
.. prompt:: bash $
|
||||
|
||||
$ export UBOOT_CFG_CORTEXR=am65x_evm_r5_defconfig
|
||||
$ export UBOOT_CFG_CORTEXA=am65x_evm_a53_defconfig
|
||||
$ export TFA_BOARD=generic
|
||||
$ # we dont use any extra TFA parameters
|
||||
$ unset TFA_EXTRA_ARGS
|
||||
$ export OPTEE_PLATFORM=k3-am65x
|
||||
$ # we dont use any extra OP-TEE parameters
|
||||
$ unset OPTEE_EXTRA_ARGS
|
||||
export UBOOT_CFG_CORTEXR=am65x_evm_r5_defconfig
|
||||
export UBOOT_CFG_CORTEXA=am65x_evm_a53_defconfig
|
||||
export TFA_BOARD=generic
|
||||
# we dont use any extra TFA parameters
|
||||
unset TFA_EXTRA_ARGS
|
||||
export OPTEE_PLATFORM=k3-am65x
|
||||
# we dont use any extra OP-TEE parameters
|
||||
unset OPTEE_EXTRA_ARGS
|
||||
|
||||
.. am65x_evm_rst_include_start_build_steps
|
||||
|
||||
|
|
@ -117,7 +117,8 @@ Set the variables corresponding to this platform:
|
|||
.. am65x_evm_rst_include_end_build_steps
|
||||
|
||||
Target Images
|
||||
--------------
|
||||
-------------
|
||||
|
||||
In order to boot we need tiboot3.bin, sysfw.itb, tispl.bin and u-boot.img.
|
||||
Each SoC variant (GP and HS) requires a different source for these files.
|
||||
|
||||
|
|
@ -159,32 +160,32 @@ 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.
|
||||
|
||||
.. code-block:: text
|
||||
.. prompt:: bash =>
|
||||
|
||||
=> 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
|
||||
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:
|
||||
|
||||
.. code-block:: text
|
||||
.. prompt:: bash =>
|
||||
|
||||
=> mmc partconf 0 1 1 1
|
||||
=> mmc bootbus 0 1 0 0
|
||||
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:
|
||||
|
||||
.. code-block:: text
|
||||
.. prompt:: bash =>
|
||||
|
||||
=> gpt write mmc 0 ${partitions}
|
||||
gpt write mmc 0 ${partitions}
|
||||
|
||||
eMMC layout:
|
||||
|
||||
|
|
@ -194,11 +195,11 @@ eMMC layout:
|
|||
Kernel image and DT are expected to be present in the /boot folder of rootfs.
|
||||
To boot kernel from eMMC, use the following commands:
|
||||
|
||||
.. code-block:: text
|
||||
.. prompt:: bash =>
|
||||
|
||||
=> setenv mmcdev 0
|
||||
=> setenv bootpart 0
|
||||
=> boot
|
||||
setenv mmcdev 0
|
||||
setenv bootpart 0
|
||||
boot
|
||||
|
||||
OSPI:
|
||||
-----
|
||||
|
|
@ -210,17 +211,17 @@ 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.
|
||||
|
||||
.. code-block:: text
|
||||
.. prompt:: bash =>
|
||||
|
||||
=> 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
|
||||
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:
|
||||
|
||||
|
|
@ -233,10 +234,10 @@ ospi.rootfs just like in SD card case. U-Boot looks for UBI volume named
|
|||
|
||||
To boot kernel from OSPI, at the U-Boot prompt:
|
||||
|
||||
.. code-block:: text
|
||||
.. prompt:: bash =>
|
||||
|
||||
=> setenv boot ubi
|
||||
=> boot
|
||||
setenv boot ubi
|
||||
boot
|
||||
|
||||
UART:
|
||||
-----
|
||||
|
|
@ -280,19 +281,19 @@ 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:
|
||||
|
||||
.. code-block:: text
|
||||
.. prompt:: bash $
|
||||
|
||||
MCU_DEV=/dev/ttyUSB1
|
||||
MAIN_DEV=/dev/ttyUSB0
|
||||
MCU_DEV=/dev/ttyUSB1
|
||||
MAIN_DEV=/dev/ttyUSB0
|
||||
|
||||
stty -F $MCU_DEV 115200 cs8 -cstopb -parenb
|
||||
stty -F $MAIN_DEV 115200 cs8 -cstopb -parenb
|
||||
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
|
||||
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
|
||||
|
||||
Debugging U-Boot
|
||||
----------------
|
||||
|
|
@ -314,6 +315,6 @@ detailed setup information.
|
|||
|
||||
To start OpenOCD and connect to the board
|
||||
|
||||
.. code-block:: bash
|
||||
.. prompt:: bash $
|
||||
|
||||
openocd -f board/ti_am654evm.cfg
|
||||
|
|
|
|||
|
|
@ -71,8 +71,7 @@ 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: =>
|
||||
.. prompt:: bash =>
|
||||
|
||||
setenv autoload no
|
||||
usb start
|
||||
|
|
|
|||
|
|
@ -64,16 +64,16 @@ Set the variables corresponding to this platform:
|
|||
.. include:: k3.rst
|
||||
:start-after: .. k3_rst_include_start_common_env_vars_defn
|
||||
:end-before: .. k3_rst_include_end_common_env_vars_defn
|
||||
.. code-block:: bash
|
||||
.. prompt:: bash $
|
||||
|
||||
$ export UBOOT_CFG_CORTEXR=j7200_evm_r5_defconfig
|
||||
$ export UBOOT_CFG_CORTEXA=j7200_evm_a72_defconfig
|
||||
$ export TFA_BOARD=generic
|
||||
$ # we dont use any extra TFA parameters
|
||||
$ unset TFA_EXTRA_ARGS
|
||||
$ export OPTEE_PLATFORM=k3-j7200
|
||||
$ # we dont use any extra OP-TEE parameters
|
||||
$ unset OPTEE_EXTRA_ARGS
|
||||
export UBOOT_CFG_CORTEXR=j7200_evm_r5_defconfig
|
||||
export UBOOT_CFG_CORTEXA=j7200_evm_a72_defconfig
|
||||
export TFA_BOARD=generic
|
||||
# we dont use any extra TFA parameters
|
||||
unset TFA_EXTRA_ARGS
|
||||
export OPTEE_PLATFORM=k3-j7200
|
||||
# we dont use any extra OP-TEE parameters
|
||||
unset OPTEE_EXTRA_ARGS
|
||||
|
||||
.. j7200_evm_rst_include_start_build_steps
|
||||
|
||||
|
|
@ -106,7 +106,8 @@ Set the variables corresponding to this platform:
|
|||
.. j7200_evm_rst_include_end_build_steps
|
||||
|
||||
Target Images
|
||||
--------------
|
||||
-------------
|
||||
|
||||
In order to boot we need tiboot3.bin, tispl.bin and u-boot.img. Each SoC
|
||||
variant (GP, HS-FS, HS-SE) requires a different source for these files.
|
||||
|
||||
|
|
@ -225,6 +226,6 @@ detailed setup information.
|
|||
|
||||
To start OpenOCD and connect to the board
|
||||
|
||||
.. code-block:: bash
|
||||
.. prompt:: bash $
|
||||
|
||||
openocd -f board/ti_j7200evm.cfg
|
||||
|
|
|
|||
|
|
@ -69,16 +69,16 @@ Set the variables corresponding to this platform:
|
|||
.. include:: k3.rst
|
||||
:start-after: .. k3_rst_include_start_common_env_vars_defn
|
||||
:end-before: .. k3_rst_include_end_common_env_vars_defn
|
||||
.. code-block:: bash
|
||||
.. prompt:: bash $
|
||||
|
||||
$ export UBOOT_CFG_CORTEXR=j721e_evm_r5_defconfig
|
||||
$ export UBOOT_CFG_CORTEXA=j721e_evm_a72_defconfig
|
||||
$ export TFA_BOARD=generic
|
||||
$ # we dont use any extra TFA parameters
|
||||
$ unset TFA_EXTRA_ARGS
|
||||
$ export OPTEE_PLATFORM=k3-j721e
|
||||
$ # we dont use any extra OP-TEE parameters
|
||||
$ unset OPTEE_EXTRA_ARGS
|
||||
export UBOOT_CFG_CORTEXR=j721e_evm_r5_defconfig
|
||||
export UBOOT_CFG_CORTEXA=j721e_evm_a72_defconfig
|
||||
export TFA_BOARD=generic
|
||||
# we dont use any extra TFA parameters
|
||||
unset TFA_EXTRA_ARGS
|
||||
export OPTEE_PLATFORM=k3-j721e
|
||||
# we dont use any extra OP-TEE parameters
|
||||
unset OPTEE_EXTRA_ARGS
|
||||
|
||||
.. j721e_evm_rst_include_start_build_steps
|
||||
|
||||
|
|
@ -111,7 +111,8 @@ Set the variables corresponding to this platform:
|
|||
.. j721e_evm_rst_include_end_build_steps
|
||||
|
||||
Target Images
|
||||
--------------
|
||||
-------------
|
||||
|
||||
In order to boot we need tiboot3.bin, sysfw.itb, tispl.bin and u-boot.img.
|
||||
Each SoC variant (GP, HS-FS and HS-SE) requires a different source for these
|
||||
files.
|
||||
|
|
@ -202,17 +203,17 @@ 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.
|
||||
|
||||
.. code-block:: text
|
||||
.. prompt:: bash =>
|
||||
|
||||
=> 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
|
||||
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:
|
||||
|
||||
|
|
@ -254,6 +255,6 @@ detailed setup information.
|
|||
|
||||
To start OpenOCD and connect to the board
|
||||
|
||||
.. code-block:: bash
|
||||
.. prompt:: bash $
|
||||
|
||||
openocd -f board/ti_j721eevm.cfg
|
||||
|
|
|
|||
|
|
@ -6,6 +6,7 @@ J721S2 and AM68 Platforms
|
|||
|
||||
Introduction:
|
||||
-------------
|
||||
|
||||
The J721S2 family of SoCs are part of K3 Multicore SoC architecture platform
|
||||
targeting automotive applications. They are designed as a low power, high
|
||||
performance and highly integrated device architecture, adding significant
|
||||
|
|
@ -38,6 +39,7 @@ Platform information:
|
|||
|
||||
Boot Flow:
|
||||
----------
|
||||
|
||||
Below is the pictorial representation of boot flow:
|
||||
|
||||
.. image:: img/boot_diagram_k3_current.svg
|
||||
|
|
@ -60,6 +62,7 @@ Sources:
|
|||
|
||||
Build procedure:
|
||||
----------------
|
||||
|
||||
0. Setup the environment variables:
|
||||
|
||||
.. include:: k3.rst
|
||||
|
|
@ -75,15 +78,15 @@ Set the variables corresponding to this platform:
|
|||
.. include:: k3.rst
|
||||
:start-after: .. k3_rst_include_start_common_env_vars_defn
|
||||
:end-before: .. k3_rst_include_end_common_env_vars_defn
|
||||
.. code-block:: bash
|
||||
.. prompt:: bash $
|
||||
|
||||
$ export UBOOT_CFG_CORTEXR=j721s2_evm_r5_defconfig
|
||||
$ export UBOOT_CFG_CORTEXA=j721s2_evm_a72_defconfig
|
||||
$ export TFA_BOARD=generic
|
||||
$ export TFA_EXTRA_ARGS="K3_USART=0x8"
|
||||
$ # The following is not a typo, j784s4 is the OP-TEE platform for j721s2
|
||||
$ export OPTEE_PLATFORM=k3-j784s4
|
||||
$ export OPTEE_EXTRA_ARGS="CFG_CONSOLE_UART=0x8"
|
||||
export UBOOT_CFG_CORTEXR=j721s2_evm_r5_defconfig
|
||||
export UBOOT_CFG_CORTEXA=j721s2_evm_a72_defconfig
|
||||
export TFA_BOARD=generic
|
||||
export TFA_EXTRA_ARGS="K3_USART=0x8"
|
||||
# The following is not a typo, j784s4 is the OP-TEE platform for j721s2
|
||||
export OPTEE_PLATFORM=k3-j784s4
|
||||
export OPTEE_EXTRA_ARGS="CFG_CONSOLE_UART=0x8"
|
||||
|
||||
.. j721s2_evm_rst_include_start_build_steps
|
||||
|
||||
|
|
@ -120,7 +123,8 @@ Set the variables corresponding to this platform:
|
|||
.. j721s2_evm_rst_include_end_build_steps
|
||||
|
||||
Target Images
|
||||
--------------
|
||||
-------------
|
||||
|
||||
In order to boot we need tiboot3.bin, tispl.bin and u-boot.img. Each SoC
|
||||
variant (GP, HS-FS, HS-SE) requires a different source for these files.
|
||||
|
||||
|
|
@ -296,7 +300,7 @@ Debugging U-Boot on J721S2-EVM
|
|||
|
||||
To start OpenOCD and connect to the board
|
||||
|
||||
.. code-block:: bash
|
||||
.. prompt:: bash $
|
||||
|
||||
openocd -f board/ti_j721s2evm.cfg
|
||||
|
||||
|
|
|
|||
|
|
@ -197,7 +197,7 @@ All of that to say you will need both a 32bit and 64bit cross compiler
|
|||
.. k3_rst_include_end_common_env_vars_desc
|
||||
|
||||
.. k3_rst_include_start_common_env_vars_defn
|
||||
.. prompt:: bash
|
||||
.. prompt:: bash $
|
||||
|
||||
export CC32=arm-linux-gnueabihf-
|
||||
export CC64=aarch64-linux-gnu-
|
||||
|
|
@ -238,7 +238,7 @@ other build sources. we shall use the following, in the build descriptions below
|
|||
.. k3_rst_include_end_board_env_vars_desc
|
||||
|
||||
Building tiboot3.bin
|
||||
^^^^^^^^^^^^^^^^^^^^^
|
||||
^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
1. To generate the U-Boot SPL for the wakeup domain, use the following
|
||||
commands, substituting :code:`{SOC}` for the name of your device (eg:
|
||||
|
|
@ -247,7 +247,7 @@ Building tiboot3.bin
|
|||
uses the split binary flow)
|
||||
|
||||
.. k3_rst_include_start_build_steps_spl_r5
|
||||
.. prompt:: bash
|
||||
.. prompt:: bash $
|
||||
|
||||
# inside u-boot source
|
||||
make $UBOOT_CFG_CORTEXR
|
||||
|
|
@ -273,7 +273,7 @@ domain of your K3 SoC.
|
|||
UBoot SPL will only look for and load the files with these names.
|
||||
|
||||
Building tispl.bin
|
||||
^^^^^^^^^^^^^^^^^^^
|
||||
^^^^^^^^^^^^^^^^^^
|
||||
|
||||
The `tispl.bin` is a standard fitImage combining the firmware need for
|
||||
the main domain to function properly as well as Device Management (DM)
|
||||
|
|
@ -283,7 +283,7 @@ firmware if your device using a split firmware.
|
|||
application cores on the main domain.
|
||||
|
||||
.. k3_rst_include_start_build_steps_tfa
|
||||
.. prompt:: bash
|
||||
.. prompt:: bash $
|
||||
|
||||
# inside trusted-firmware-a source
|
||||
make CROSS_COMPILE=$CC64 ARCH=aarch64 PLAT=k3 SPD=opteed $TFA_EXTRA_ARGS \
|
||||
|
|
@ -299,7 +299,7 @@ use the `lite` option.
|
|||
using the TrustZone technology built into the core.
|
||||
|
||||
.. k3_rst_include_start_build_steps_optee
|
||||
.. prompt:: bash
|
||||
.. prompt:: bash $
|
||||
|
||||
# inside optee_os source
|
||||
make CROSS_COMPILE=$CC32 CROSS_COMPILE64=$CC64 CFG_ARM64_core=y $OPTEE_EXTRA_ARGS \
|
||||
|
|
@ -311,7 +311,7 @@ use the `lite` option.
|
|||
64bit core in the main domain.
|
||||
|
||||
.. k3_rst_include_start_build_steps_uboot
|
||||
.. prompt:: bash
|
||||
.. prompt:: bash $
|
||||
|
||||
# inside u-boot source
|
||||
make $UBOOT_CFG_CORTEXA
|
||||
|
|
@ -410,14 +410,14 @@ and the same can be extended to other platforms
|
|||
be passing to mkimage for signing the fitImage and embedding the key in
|
||||
the u-boot dtb.
|
||||
|
||||
.. prompt:: bash
|
||||
.. prompt:: bash $
|
||||
|
||||
mkimage -r -f fitImage.its -k $UBOOT_PATH/board/ti/keys -K
|
||||
$UBOOT_PATH/build/a72/dts/dt.dtb
|
||||
|
||||
For signing a secondary platform, pass the -K parameter to that DTB
|
||||
|
||||
.. prompt:: bash
|
||||
.. prompt:: bash $
|
||||
|
||||
mkimage -f fitImage.its -k $UBOOT_PATH/board/ti/keys -K
|
||||
$UBOOT_PATH/build/a72/arch/arm/dts/k3-j721e-sk.dtb
|
||||
|
|
@ -476,8 +476,7 @@ then the saveenv command and can be used across various bootmodes too.
|
|||
|
||||
**Writing to MMC/EMMC**
|
||||
|
||||
.. prompt:: bash
|
||||
:prompts: =>
|
||||
.. prompt:: bash =>
|
||||
|
||||
env export -t $loadaddr <list of variables>
|
||||
fatwrite mmc ${mmcdev} ${loadaddr} ${bootenvfile} ${filesize}
|
||||
|
|
@ -490,8 +489,7 @@ mmcdev) and set the environments.
|
|||
If manually needs to be done then the environment can be read from the
|
||||
filesystem and then imported
|
||||
|
||||
.. prompt:: bash
|
||||
:prompts: =>
|
||||
.. prompt:: bash =>
|
||||
|
||||
fatload mmc ${mmcdev} ${loadaddr} ${bootenvfile}
|
||||
env import -t ${loadaddr} ${filesize}
|
||||
|
|
@ -551,7 +549,7 @@ Refer to the release notes corresponding to the `OpenOCD version
|
|||
box support by OpenOCD. The board-specific documentation will
|
||||
cover the details and any adapter/dongle recommendations.
|
||||
|
||||
.. prompt:: bash
|
||||
.. prompt:: bash $
|
||||
|
||||
openocd -v
|
||||
|
||||
|
|
@ -569,7 +567,7 @@ systems, but equivalent instructions should exist for systems with
|
|||
other package managers. Please refer to the `OpenOCD Documentation
|
||||
<https://openocd.org/>`_ for more recent installation steps.
|
||||
|
||||
.. prompt:: bash
|
||||
.. prompt:: bash $
|
||||
|
||||
# Check the packages to be installed: needs deb-src in sources.list
|
||||
sudo apt build-dep openocd
|
||||
|
|
@ -599,7 +597,7 @@ The step is not necessary if the distribution supports the OpenOCD, but
|
|||
if building from a source, ensure that the udev rules are installed
|
||||
correctly to ensure a sane system.
|
||||
|
||||
.. prompt:: bash
|
||||
.. prompt:: bash $
|
||||
|
||||
# Go to the OpenOCD source directory
|
||||
cd openocd
|
||||
|
|
@ -617,7 +615,7 @@ Step 2: Setup GDB
|
|||
|
||||
Most systems come with gdb-multiarch package.
|
||||
|
||||
.. prompt:: bash
|
||||
.. prompt:: bash $
|
||||
|
||||
# Install gdb-multiarch package
|
||||
sudo apt-get install gdb-multiarch
|
||||
|
|
@ -833,7 +831,7 @@ Startup OpenOCD to debug the platform as follows:
|
|||
|
||||
.. k3_rst_include_start_openocd_cfg_XDS110
|
||||
|
||||
.. prompt:: bash
|
||||
.. prompt:: bash $
|
||||
|
||||
openocd -f board/{board_of_choice}.cfg
|
||||
|
||||
|
|
@ -847,7 +845,7 @@ Startup OpenOCD to debug the platform as follows:
|
|||
<https://github.com/openocd-org/openocd/blob/master/tcl/target/ti_k3.cfg#L59>`_
|
||||
to decide if the SoC is supported or not.
|
||||
|
||||
.. prompt:: bash
|
||||
.. prompt:: bash $
|
||||
|
||||
openocd -f openocd_connect.cfg
|
||||
|
||||
|
|
@ -922,13 +920,13 @@ To debug using this server, use GDB directly or your preferred
|
|||
GDB-based IDE. To start up GDB in the terminal, run the following
|
||||
command.
|
||||
|
||||
.. prompt:: bash
|
||||
.. prompt:: bash $
|
||||
|
||||
gdb-multiarch
|
||||
|
||||
To connect to your desired core, run the following command within GDB:
|
||||
|
||||
.. code-block:: bash
|
||||
.. prompt:: bash (gdb)
|
||||
|
||||
target extended-remote localhost:{port for desired core}
|
||||
|
||||
|
|
@ -945,13 +943,13 @@ To load symbols:
|
|||
|
||||
* Prior to relocation:
|
||||
|
||||
.. code-block:: bash
|
||||
.. prompt:: bash (gdb)
|
||||
|
||||
symbol-file {path to elf file}
|
||||
|
||||
* After relocation:
|
||||
|
||||
.. code-block:: bash
|
||||
.. prompt:: bash (gdb)
|
||||
|
||||
# Drop old symbol file
|
||||
symbol-file
|
||||
|
|
@ -962,7 +960,7 @@ To load symbols:
|
|||
|
||||
In the above example of AM625,
|
||||
|
||||
.. code-block:: bash
|
||||
.. prompt:: bash (gdb)
|
||||
|
||||
target extended-remote localhost:3338 <- R5F (Wakeup Domain)
|
||||
target extended-remote localhost:3334 <- A53 (Main Domain)
|
||||
|
|
@ -982,7 +980,7 @@ breakpoints. To exit the debug loop added above, add any breakpoints
|
|||
needed and run the following GDB commands to step out of the debug
|
||||
loop set in the ``board_init_f`` function.
|
||||
|
||||
.. code-block:: bash
|
||||
.. prompt:: bash (gdb)
|
||||
|
||||
set x = 0
|
||||
continue
|
||||
|
|
|
|||
|
|
@ -122,8 +122,7 @@ Don't forget to add CROSS_COMPILE.
|
|||
|
||||
To build u-boot.bin, u-boot-spi.gph, MLO:
|
||||
|
||||
.. prompt:: bash
|
||||
:prompts: $
|
||||
.. prompt:: bash $
|
||||
|
||||
make k2hk_evm_defconfig
|
||||
make
|
||||
|
|
@ -197,8 +196,7 @@ instructions:
|
|||
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: =>
|
||||
.. prompt:: bash =>
|
||||
|
||||
setenv addr_uboot 0x87000000
|
||||
setenv filesize <size in hex of u-boot-spi.gph rounded to hex 0x10000>
|
||||
|
|
@ -226,8 +224,7 @@ instructions:
|
|||
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: =>
|
||||
.. prompt:: bash =>
|
||||
|
||||
setenv filesize <size in hex of MLO rounded to hex 0x10000>
|
||||
run burn_uboot_nand
|
||||
|
|
@ -249,10 +246,10 @@ 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
|
||||
.. prompt:: bash BMC>
|
||||
|
||||
BMC> bootmode #4
|
||||
MBC> reboot
|
||||
bootmode #4
|
||||
reboot
|
||||
|
||||
3. When xmodem is complete you should see the U-Boot starts on the UART port
|
||||
|
||||
|
|
|
|||
|
|
@ -2,7 +2,7 @@
|
|||
.. (C) Copyright 2019 Xilinx, Inc.
|
||||
|
||||
U-Boot device tree bindings
|
||||
----------------------------
|
||||
---------------------------
|
||||
|
||||
All the device tree bindings used in U-Boot are specified in Linux
|
||||
kernel. Please refer dt bindings from below specified paths in Linux
|
||||
|
|
|
|||
2
doc/build/gcc.rst
vendored
2
doc/build/gcc.rst
vendored
|
|
@ -66,7 +66,7 @@ For building U-Boot on Alpine Linux at least the following packages are needed:
|
|||
Depending on the build target further packages may be needed:
|
||||
|
||||
* sandbox with lcd: sdl2-dev
|
||||
* riscv64 S-mode targests: opensbi
|
||||
* riscv64 S-mode targets: opensbi
|
||||
* some arm64 targets: arm-trusted-firmware
|
||||
|
||||
Prerequisites
|
||||
|
|
|
|||
2
doc/build/source.rst
vendored
2
doc/build/source.rst
vendored
|
|
@ -1,5 +1,5 @@
|
|||
Obtaining the source
|
||||
=====================
|
||||
====================
|
||||
|
||||
The source of the U-Boot project is maintained in a Git repository.
|
||||
|
||||
|
|
|
|||
|
|
@ -1,5 +1,5 @@
|
|||
Ethernet Driver Guide
|
||||
=======================
|
||||
=====================
|
||||
|
||||
The networking stack in Das U-Boot is designed for multiple network devices
|
||||
to be easily added and controlled at runtime. This guide is meant for people
|
||||
|
|
@ -14,7 +14,7 @@ Some drivers are still using the old Ethernet interface, differences between
|
|||
the two and hints about porting will be handled at the end.
|
||||
|
||||
Driver framework
|
||||
------------------
|
||||
----------------
|
||||
|
||||
A network driver following the driver model must declare itself using
|
||||
the UCLASS_ETH .id field in the U-Boot driver struct:
|
||||
|
|
@ -67,7 +67,7 @@ bus. Also it would take care of any special PHY setup (power rails, enable
|
|||
bits for internal PHYs, etc.).
|
||||
|
||||
Driver methods
|
||||
----------------
|
||||
--------------
|
||||
|
||||
The real work will be done in the driver method functions the driver provides
|
||||
by defining the members of struct eth_ops:
|
||||
|
|
@ -158,7 +158,7 @@ So the call graph at this stage would look something like:
|
|||
|
||||
|
||||
CONFIG_PHYLIB / CONFIG_CMD_MII
|
||||
--------------------------------
|
||||
------------------------------
|
||||
|
||||
If your device supports banging arbitrary values on the MII bus (pretty much
|
||||
every device does), you should add support for the mii command. Doing so is
|
||||
|
|
@ -193,7 +193,7 @@ should logically follow.
|
|||
................................................................
|
||||
|
||||
Legacy network drivers
|
||||
------------------------
|
||||
----------------------
|
||||
|
||||
!!! WARNING !!!
|
||||
|
||||
|
|
@ -221,7 +221,7 @@ instructions on how to port this over. For the records, the old way of
|
|||
initialising a network driver is as follows:
|
||||
|
||||
Old network driver registration
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
When U-Boot initializes, it will call the common function eth_initialize().
|
||||
This will in turn call the board-specific board_eth_init() (or if that fails,
|
||||
|
|
|
|||
|
|
@ -100,7 +100,7 @@ Maintainers should submit patches switching over to using CONFIG_DM_I2C and
|
|||
other base driver model options in time for inclusion in the 2021.10 release.
|
||||
|
||||
CFG_SYS_TIMER_RATE and CFG_SYS_TIMER_COUNTER
|
||||
--------------------------------------------------
|
||||
--------------------------------------------
|
||||
Deadline: 2023.01
|
||||
|
||||
These are legacy options which have been replaced by driver model.
|
||||
|
|
|
|||
|
|
@ -1,7 +1,7 @@
|
|||
.. SPDX-License-Identifier: GPL-2.0+
|
||||
|
||||
NVM XIP Block Storage Emulation Driver
|
||||
=======================================
|
||||
======================================
|
||||
|
||||
Summary
|
||||
-------
|
||||
|
|
@ -54,12 +54,12 @@ The NVMXIP Uclass provides the following drivers:
|
|||
The implementation is generic and can be used by different platforms.
|
||||
|
||||
Supported hardware
|
||||
--------------------------------
|
||||
------------------
|
||||
|
||||
Any plaform supporting readq().
|
||||
|
||||
Configuration
|
||||
----------------------
|
||||
-------------
|
||||
|
||||
config NVMXIP
|
||||
This option allows the emulation of a block storage device
|
||||
|
|
@ -77,7 +77,7 @@ config NVMXIP_QSPI
|
|||
write their own driver (same as nvmxip_qspi in addition to the custom settings).
|
||||
|
||||
Device Tree nodes
|
||||
--------------------
|
||||
-----------------
|
||||
|
||||
Multiple QSPI XIP flash devices can be used at the same time by describing them through DT
|
||||
nodes.
|
||||
|
|
|
|||
|
|
@ -218,7 +218,7 @@ DM tells you. The name is not quite right. So in this case we would use:
|
|||
|
||||
|
||||
Write of_to_plat() [for device tree only]
|
||||
-------------------------------------------------
|
||||
-----------------------------------------
|
||||
|
||||
This method will convert information in the device tree node into a C
|
||||
structure in your driver (called platform data). If you are not using
|
||||
|
|
|
|||
|
|
@ -220,7 +220,7 @@ setting the GPIO (on twister GPIO 55 is used) to kernel mode.
|
|||
The kernel is loaded directly by the SPL without passing through U-Boot.
|
||||
|
||||
Example with FDT: a3m071 board
|
||||
-------------------------------
|
||||
------------------------------
|
||||
|
||||
To boot the Linux kernel from the SPL, the DT blob (fdt) needs to get
|
||||
prepared/patched first. U-Boot usually inserts some dynamic values into
|
||||
|
|
|
|||
|
|
@ -1,7 +1,7 @@
|
|||
.. SPDX-License-Identifier: GPL-2.0+:
|
||||
|
||||
askenv command
|
||||
===============
|
||||
==============
|
||||
|
||||
Synopsis
|
||||
--------
|
||||
|
|
|
|||
|
|
@ -76,7 +76,7 @@ name is provided, all hunters are run.
|
|||
|
||||
|
||||
bootdev select
|
||||
~~~~~~~~~~~~~~~~~
|
||||
~~~~~~~~~~~~~~
|
||||
|
||||
Use this to select a particular bootdev. You can select it by the sequence
|
||||
number or name, as shown in `bootdev list`.
|
||||
|
|
@ -89,7 +89,7 @@ unselected.
|
|||
|
||||
|
||||
bootdev info
|
||||
~~~~~~~~~~~~~~~
|
||||
~~~~~~~~~~~~
|
||||
|
||||
This shows information on the current bootdev, with the format looking like
|
||||
this:
|
||||
|
|
|
|||
|
|
@ -1,7 +1,7 @@
|
|||
.. SPDX-License-Identifier: GPL-2.0+:
|
||||
|
||||
cat command
|
||||
===============
|
||||
===========
|
||||
|
||||
Synopsis
|
||||
--------
|
||||
|
|
|
|||
|
|
@ -21,7 +21,7 @@ environment variables stdin, stdout, stderr which contain a comma separated
|
|||
list of device names.
|
||||
|
||||
Example
|
||||
--------
|
||||
-------
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
|
|
|
|||
|
|
@ -1,7 +1,7 @@
|
|||
.. SPDX-License-Identifier: GPL-2.0+:
|
||||
|
||||
mmc command
|
||||
============
|
||||
===========
|
||||
|
||||
Synopsis
|
||||
--------
|
||||
|
|
|
|||
|
|
@ -1,7 +1,7 @@
|
|||
.. SPDX-License-Identifier: GPL-2.0+:
|
||||
|
||||
part command
|
||||
===============
|
||||
============
|
||||
|
||||
Synopis
|
||||
-------
|
||||
|
|
|
|||
|
|
@ -15,7 +15,7 @@ Synopsis
|
|||
Description
|
||||
-----------
|
||||
|
||||
The *qfw* command is used to retrieve information form the QEMU firmware.
|
||||
The *qfw* command is used to retrieve information from the QEMU firmware.
|
||||
|
||||
The *qfw list* sub-command displays the QEMU firmware files.
|
||||
|
||||
|
|
|
|||
|
|
@ -1,7 +1,7 @@
|
|||
.. SPDX-License-Identifier: GPL-2.0+:
|
||||
|
||||
wdt command
|
||||
============
|
||||
===========
|
||||
|
||||
Synopsis
|
||||
--------
|
||||
|
|
|
|||
|
|
@ -1,7 +1,7 @@
|
|||
.. SPDX-License-Identifier: GPL-2.0+:
|
||||
|
||||
xxd command
|
||||
===============
|
||||
===========
|
||||
|
||||
Synopsis
|
||||
--------
|
||||
|
|
|
|||
|
|
@ -86,7 +86,7 @@ c. You will now have a U-Boot image::
|
|||
|
||||
|
||||
Step 2: Build Linux
|
||||
--------------------
|
||||
-------------------
|
||||
|
||||
a. Find the kernel image ('Image') and device tree (.dtb) file you plan to
|
||||
use. In our case it is am335x-boneblack.dtb and it is built with the kernel.
|
||||
|
|
|
|||
|
|
@ -1,7 +1,7 @@
|
|||
.. SPDX-License-Identifier: GPL-2.0+
|
||||
|
||||
Measured Boot
|
||||
=====================
|
||||
=============
|
||||
|
||||
U-Boot can perform a measured boot, the process of hashing various components
|
||||
of the boot process, extending the results in the TPM and logging the
|
||||
|
|
@ -16,7 +16,7 @@ TPM PCRs match the contents of the event log. This can further be checked
|
|||
against the hash results of previous boots.
|
||||
|
||||
Requirements
|
||||
---------------------
|
||||
------------
|
||||
|
||||
* A hardware TPM 2.0 supported by the U-Boot drivers
|
||||
* CONFIG_TPM=y
|
||||
|
|
|
|||
|
|
@ -1,5 +1,5 @@
|
|||
Binman Entry Documentation
|
||||
===========================
|
||||
==========================
|
||||
|
||||
This file describes the entry types supported by binman. These entry types can
|
||||
be placed in an image one by one to build up a final firmware image. It is
|
||||
|
|
|
|||
Loading…
Reference in a new issue