mirror of
https://github.com/AsahiLinux/u-boot
synced 2024-11-24 13:43:28 +00:00
doc: shorten overlong title underlines
Title underlines should match the length of the title. Unfortunately docutils only catches underlines that are too short. Add some missing empty lines after titles. Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
This commit is contained in:
Heinrich Schuchardt
parent
0e20948598
commit
b214e88071
43 changed files with 86 additions and 70 deletions
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -70,7 +70,7 @@ Set the variables corresponding to this platform:
|
|||
: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
|
||||
|
|
|
|||
|
|
@ -2,7 +2,7 @@
|
|||
.. sectionauthor:: Vignesh Raghavendra <vigneshr@ti.com>
|
||||
|
||||
AM62 Platforms
|
||||
===============
|
||||
==============
|
||||
|
||||
Introduction:
|
||||
-------------
|
||||
|
|
@ -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.
|
||||
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
@ -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.
|
||||
|
||||
|
|
|
|||
|
|
@ -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:
|
||||
|
|
@ -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)
|
||||
|
|
|
|||
|
|
@ -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/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
|
||||
-------
|
||||
|
|
|
|||
|
|
@ -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