- 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
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
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.
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.
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.
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
- FF-A bus can be compiled and used without EFI
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.
.. 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.
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
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
.. Copyright (C) 2020 Amit Singh Tomar <amittomer25@gmail.com>
Actions
-========
+=======
.. toctree::
:maxdepth: 2
.. SPDX-License-Identifier: GPL-2.0
Arm Ltd
-=============
+=======
.. toctree::
:maxdepth: 2
.. SPDX-License-Identifier: GPL-2.0+
Mediatek
-=========
+========
.. toctree::
:maxdepth: 2
$ cp firmware-imx-8.9/firmware/ddr/synopsys/lpddr4*.bin $(builddir)
Build U-Boot for sd card
---------------------------
+------------------------
.. code-block:: bash
----
Set Boot switch to SD boot
-Build U-Boot for qspi flash card
-------------------------------------
+Build U-Boot for qspi flash card
+--------------------------------
.. code-block:: bash
$ 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
- ARM JTAG support
Memory map from core's view
-----------------------------
+---------------------------
================== ================== ================ =====
Start Address End Address Description Size
===============
How to use U-Boot on Freescale MX6UL 14x14 EVK
------------------------------------------------
+----------------------------------------------
- Build U-Boot for MX6UL 14x14 EVK:
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
.. SPDX-License-Identifier: GPL-2.0+
Librem5
-==========
+=======
U-Boot for the Purism Librem5 phone
.. 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.
Installation
------------
+
Build
^^^^^
+
Setup ``CROSS_COMPILE`` for aarch64 and build U-Boot for your board::
$ export CROSS_COMPILE=<aarch64 toolchain prefix>
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.
.. SPDX-License-Identifier: GPL-2.0+
Samsung
-========
+=======
.. toctree::
:maxdepth: 2
.. 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
.. sectionauthor:: Patrice Chotard <patrice.chotardy@foss.st.com>
STM32 MCU boards
-=================
+================
This is a quick instruction for setup STM32 MCU boards.
====================
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
.. SPDX-License-Identifier: GPL-2.0+
T-HEAD
-========
+======
.. toctree::
:maxdepth: 1
: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
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
.. sectionauthor:: Vignesh Raghavendra <vigneshr@ti.com>
AM62 Platforms
-===============
+==============
Introduction:
-------------
.. 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.
.. 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.
.. 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.
.. 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.
.. 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.
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
Boot Flow:
----------
+
Below is the pictorial representation of boot flow:
.. image:: img/boot_diagram_k3_current.svg
Build procedure:
----------------
+
0. Setup the environment variables:
.. include:: k3.rst
.. 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.
.. 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:
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)
.. (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
Obtaining the source
-=====================
+====================
The source of the U-Boot project is maintained in a Git repository.
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
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:
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:
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
................................................................
Legacy network drivers
-------------------------
+----------------------
!!! WARNING !!!
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,
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.
.. SPDX-License-Identifier: GPL-2.0+
NVM XIP Block Storage Emulation Driver
-=======================================
+======================================
Summary
-------
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
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.
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
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
.. SPDX-License-Identifier: GPL-2.0+:
askenv command
-===============
+==============
Synopsis
--------
bootdev select
-~~~~~~~~~~~~~~~~~
+~~~~~~~~~~~~~~
Use this to select a particular bootdev. You can select it by the sequence
number or name, as shown in `bootdev list`.
bootdev info
-~~~~~~~~~~~~~~~
+~~~~~~~~~~~~
This shows information on the current bootdev, with the format looking like
this:
.. SPDX-License-Identifier: GPL-2.0+:
cat command
-===============
+===========
Synopsis
--------
list of device names.
Example
---------
+-------
.. code-block:: console
.. SPDX-License-Identifier: GPL-2.0+:
mmc command
-============
+===========
Synopsis
--------
.. SPDX-License-Identifier: GPL-2.0+:
part command
-===============
+============
Synopis
-------
.. SPDX-License-Identifier: GPL-2.0+:
wdt command
-============
+===========
Synopsis
--------
.. SPDX-License-Identifier: GPL-2.0+:
xxd command
-===============
+===========
Synopsis
--------
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.
.. 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
against the hash results of previous boots.
Requirements
----------------------
+------------
* A hardware TPM 2.0 supported by the U-Boot drivers
* CONFIG_TPM=y
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
projects / u-boot.git / commitdiff