summaryrefslogtreecommitdiff
path: root/doc/usage
diff options
context:
space:
mode:
Diffstat (limited to 'doc/usage')
-rw-r--r--doc/usage/cmd/bootmeth.rst2
-rw-r--r--doc/usage/fit/beaglebone_vboot.rst21
-rw-r--r--doc/usage/fit/signature.rst2
-rw-r--r--doc/usage/fit/source_file_format.rst34
-rw-r--r--doc/usage/measured_boot.rst35
-rw-r--r--doc/usage/netconsole.rst55
6 files changed, 105 insertions, 44 deletions
diff --git a/doc/usage/cmd/bootmeth.rst b/doc/usage/cmd/bootmeth.rst
index 2903977ee54..bac9fdf85cd 100644
--- a/doc/usage/cmd/bootmeth.rst
+++ b/doc/usage/cmd/bootmeth.rst
@@ -48,7 +48,7 @@ The format looks like this:
===== === ================== =================================
Order Seq Name Description
===== === ================== =================================
- 0 0 extlinunx Extlinux boot from a block device
+ 0 0 extlinux Extlinux boot from a block device
1 1 efi EFI boot from an .efi file
2 2 pxe PXE boot from a network device
3 3 sandbox Sandbox boot for testing
diff --git a/doc/usage/fit/beaglebone_vboot.rst b/doc/usage/fit/beaglebone_vboot.rst
index cd6bb141910..1298ba1ae08 100644
--- a/doc/usage/fit/beaglebone_vboot.rst
+++ b/doc/usage/fit/beaglebone_vboot.rst
@@ -67,18 +67,20 @@ a. Set up the environment variable to point to your toolchain. You will need
export CROSS_COMPILE=arm-linux-gnueabi-
-b. Configure and build U-Boot with verified boot enabled::
+b. Configure and build U-Boot with verified boot enabled. Note that we use the
+am335x_evm target since it covers all boards based on the AM335x evaluation
+board::
export UBOOT=/path/to/u-boot
cd $UBOOT
# You can add -j10 if you have 10 CPUs to make it faster
- make O=b/am335x_boneblack_vboot am335x_boneblack_vboot_config all
- export UOUT=$UBOOT/b/am335x_boneblack_vboot
+ make O=b/am335x_evm am335x_evm_config all
+ export UOUT=$UBOOT/b/am335x_evm
c. You will now have a U-Boot image::
- file b/am335x_boneblack_vboot/u-boot-dtb.img
- b/am335x_boneblack_vboot/u-boot-dtb.img: u-boot legacy uImage,
+ file b/am335x_evm/u-boot-dtb.img
+ b/am335x_evm/u-boot-dtb.img: u-boot legacy uImage,
U-Boot 2014.07-rc2-00065-g2f69f8, Firmware/ARM, Firmware Image
(Not compressed), 395375 bytes, Sat May 31 16:19:04 2014,
Load Address: 0x80800000, Entry Point: 0x00000000,
@@ -466,7 +468,7 @@ the private key that you signed with so that it can verify any kernels that
you sign::
cd $UBOOT
- make O=b/am335x_boneblack_vboot EXT_DTB=${WORK}/am335x-boneblack-pubkey.dtb
+ make O=b/am335x_evm EXT_DTB=${WORK}/am335x-boneblack-pubkey.dtb
Here we are overriding the normal device tree file with our one, which
contains the public key.
@@ -597,14 +599,11 @@ Further Improvements
Several of the steps here can be easily automated. In particular it would be
capital if signing and packaging a kernel were easy, perhaps a simple make
-target in the kernel.
+target in the kernel. A starting point for this is the 'make image.fit' target
+for ARM64 in Linux from v6.9 onwards.
Some mention of how to use multiple .dtb files in a FIT might be useful.
-U-Boot's verified boot mechanism has not had a robust and independent security
-review. Such a review should look at the implementation and its resistance to
-attacks.
-
Perhaps the verified boot feature could be integrated into the Amstrom
distribution.
diff --git a/doc/usage/fit/signature.rst b/doc/usage/fit/signature.rst
index 03a71b5192d..b868dcbf9fd 100644
--- a/doc/usage/fit/signature.rst
+++ b/doc/usage/fit/signature.rst
@@ -15,7 +15,7 @@ that it can be verified using a public key later. Provided that the private
key is kept secret and the public key is stored in a non-volatile place,
any image can be verified in this way.
-See verified-boot.txt for more general information on verified boot.
+See :doc:`verified-boot` for more general information on verified boot.
Concepts
diff --git a/doc/usage/fit/source_file_format.rst b/doc/usage/fit/source_file_format.rst
index b2b1e42bd73..15990e3ff54 100644
--- a/doc/usage/fit/source_file_format.rst
+++ b/doc/usage/fit/source_file_format.rst
@@ -192,13 +192,13 @@ type
invalid Invalid Image
aisimage Davinci AIS image
atmelimage ATMEL ROM-Boot Image
- copro Coprocessor Image}
+ copro Coprocessor Image
fdt_legacy legacy Image with Flat Device Tree
filesystem Filesystem Image
firmware Firmware
- firmware_ivt Firmware with HABv4 IVT }
+ firmware_ivt Firmware with HABv4 IVT
flat_dt Flat Device Tree
- fpga FPGA Image }
+ fpga FPGA Device Image (bitstream file, vendor specific)
gpimage TI Keystone SPL Image
imx8image NXP i.MX8 Boot Image
imx8mimage NXP i.MX8M Boot Image
@@ -207,31 +207,31 @@ type
kernel_noload Kernel Image (no loading done)
kwbimage Kirkwood Boot Image
lpc32xximage LPC32XX Boot Image
- mtk_image MediaTek BootROM loadable Image }
+ mtk_image MediaTek BootROM loadable Image
multi Multi-File Image
mxsimage Freescale MXS Boot Image
omapimage TI OMAP SPL With GP CH
pblimage Freescale PBL Boot Image
pmmc TI Power Management Micro-Controller Firmware
ramdisk RAMDisk Image
- rkimage Rockchip Boot Image }
- rksd Rockchip SD Boot Image }
- rkspi Rockchip SPI Boot Image }
+ rkimage Rockchip Boot Image
+ rksd Rockchip SD Boot Image
+ rkspi Rockchip SPI Boot Image
script Script
socfpgaimage Altera SoCFPGA CV/AV preloader
socfpgaimage_v1 Altera SoCFPGA A10 preloader
- spkgimage Renesas SPKG Image }
+ spkgimage Renesas SPKG Image
standalone Standalone Program
- stm32image STMicroelectronics STM32 Image }
- sunxi_egon Allwinner eGON Boot Image }
- sunxi_toc0 Allwinner TOC0 Boot Image }
+ stm32image STMicroelectronics STM32 Image
+ sunxi_egon Allwinner eGON Boot Image
+ sunxi_toc0 Allwinner TOC0 Boot Image
tee Trusted Execution Environment Image
ublimage Davinci UBL image
vybridimage Vybrid Boot Image
x86_setup x86 setup.bin
- zynqimage Xilinx Zynq Boot Image }
- zynqmpbif Xilinx ZynqMP Boot Image (bif) }
- zynqmpimage Xilinx ZynqMP Boot Image }
+ zynqimage Xilinx Zynq Boot Image
+ zynqmpbif Xilinx ZynqMP Boot Image (bif)
+ zynqmpimage Xilinx ZynqMP Boot Image
==================== ==================
compression
@@ -254,9 +254,6 @@ compression
zstd zstd compressed
==================== ==================
-data-size
- size of the data in bytes
-
Conditionally mandatory property
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -276,6 +273,9 @@ data-position
not relative to the loading of the FIT. This is mandatory if external data
used with a fixed address.
+data-size
+ Size of the data in bytes. This is mandatory if external data is used.
+
os
OS name, mandatory for types "kernel". Valid OS names are:
diff --git a/doc/usage/measured_boot.rst b/doc/usage/measured_boot.rst
index 9691904a9d8..05c439e9ac6 100644
--- a/doc/usage/measured_boot.rst
+++ b/doc/usage/measured_boot.rst
@@ -7,19 +7,46 @@ 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
component's measurement in memory for the operating system to consume.
+The functionality is available when booting via the EFI subsystem or 'bootm'
+command.
+
+UEFI measured boot
+------------------
+
+The EFI subsystem implements the `EFI TCG protocol
+<https://trustedcomputinggroup.org/resource/tcg-efi-protocol-specification/>`_
+and the `TCG PC Client Specific Platform Firmware Profile Specification
+<https://trustedcomputinggroup.org/resource/pc-client-specific-platform-firmware-profile-specification/>`_
+which defines the binaries to be measured and the corresponding PCRs to be used.
+
+Requirements
+~~~~~~~~~~~~
+
+* A hardware TPM 2.0 supported by an enabled U-Boot driver
+* CONFIG_EFI_TCG2_PROTOCOL=y
+* CONFIG_EFI_TCG2_PROTOCOL_EVENTLOG_SIZE=y
+* optional CONFIG_EFI_TCG2_PROTOCOL_MEASURE_DTB=y will measure the loaded DTB
+ in PCR 1
+
+Legacy measured boot
+--------------------
+
+The commands booti, bootm, and bootz can be used for measured boot
+using the legacy entry point of the Linux kernel.
+
By default, U-Boot will measure the operating system (linux) image, the
initrd image, and the "bootargs" environment variable. By enabling
-CONFIG_MEASURE_DEVICETREE, U-Boot will also measure the devicetree image.
+CONFIG_MEASURE_DEVICETREE, U-Boot will also measure the devicetree image in PCR1.
The operating system typically would verify that the hashes found in the
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
+* A hardware TPM 2.0 supported by an enabled U-Boot driver
+* CONFIG_TPMv2=y
* CONFIG_MEASURED_BOOT=y
* Device-tree configuration of the TPM device to specify the memory area
for event logging. The TPM device node must either contain a phandle to
diff --git a/doc/usage/netconsole.rst b/doc/usage/netconsole.rst
index 2aa3b9ccc59..df27b78342f 100644
--- a/doc/usage/netconsole.rst
+++ b/doc/usage/netconsole.rst
@@ -3,10 +3,10 @@ Network console
In U-Boot, we implemented the networked console via the standard
"devices" mechanism, which means that you can switch between the
-serial and network input/output devices by adjusting the 'stdin' and
-'stdout' environment variables. To switch to the networked console,
-set either of these variables to "nc". Input and output can be
-switched independently.
+serial and network input/output devices by adjusting the 'stdin',
+'stdout', and 'stderr' environment variables. To switch to the
+networked console, set either of these variables to "nc". Input and
+output can be switched independently.
The default buffer size can be overridden by setting
CFG_NETCONSOLE_BUFFER_SIZE.
@@ -18,14 +18,18 @@ broadcast address and port 6666 are used. If it is set to an IP
address of 0 (or 0.0.0.0) then no messages are sent to the network.
The source / listening port can be configured separately by setting
the 'ncinport' environment variable and the destination port can be
-configured by setting the 'ncoutport' environment variable.
+configured by setting the 'ncoutport' environment variable. Note that
+you need to set up the network interface (e.g. using DHCP) before it
+can be used for network console.
-For example, if your server IP is 192.168.1.1, you could use::
+For example, if your server IP is 192.168.1.1, you could use:
- => setenv nc 'setenv stdout nc;setenv stdin nc'
- => setenv ncip 192.168.1.1
- => saveenv
- => run nc
+.. prompt:: bash =>
+
+ env set nc 'env set stdout nc; env set stderr nc; env set stdin nc'
+ env set ncip '192.168.1.1'
+ env save
+ run nc
On the host side, please use this script to access the console
@@ -107,3 +111,34 @@ as follows:
Note that unlike the U-Boot implementation the Linux netconsole is
unidirectional, i. e. you have console output only in Linux.
+
+Setup via environment
+---------------------
+
+If persistent environment is enabled in your U-Boot configuration, you
+can configure the network console using the environment. For example:
+
+.. prompt:: bash =>
+
+ env set autoload no
+ env set hostname "u-boot"
+ env set bootdelay 5
+ env set nc 'dhcp; env set stdout nc; env set stderr nc; env set stdin nc'
+ env set ncip '192.168.1.1'
+ env set preboot "${preboot}; run nc;"
+ env save
+ reset
+
+``autoload no`` tells the ``dhcp`` command to configure the network
+interface without trying to load an image. ``hostname "u-boot"`` sets
+the hostname to be sent in DHCP requests, so they are easy to
+recognize in the DHCP server log. The command in ``nc`` calls ``dhcp``
+to make sure the network interface is set up before enabling
+netconsole.
+
+Adding ``nc`` to ``preboot`` tells U-Boot to activate netconsole
+before trying to find any boot options, so you can interact with it if
+desired.
+
+``env save`` stores the settings persistently, and ``reset`` then
+triggers a fresh start that will use the changed settings.