u-boot/doc/usage/cmd/bootm.rst
Simon Glass 35ed599f43 doc: Improve documentation for the bootm command
Reformat and rewrite the documentation for this command.

This is a complicated command, so further improvements are welcome.

Signed-off-by: Simon Glass <sjg@chromium.org>
2023-06-23 16:28:13 +02:00

300 lines
8 KiB
ReStructuredText

.. SPDX-License-Identifier: GPL-2.0+
bootm command
=============
Synopsis
--------
::
bootm [fit_addr]#<conf>[#extra-conf]
bootm [[fit_addr]:<os_subimg>] [[<fit_addr2>]:<rd_subimg2>] [[<fit_addr3>]:<fdt_subimg>]
bootm <addr1> [[<addr2> [<addr3>]] # Legacy boot
Description
-----------
The *bootm* command is used to boot an Operating System. It has a large number
of options depending on what needs to be booted.
Note that the second form supports the first and/or second arguments to be
omitted by using a hyphen '-' instead.
fit_addr / fit_addr2 / fit_addr3
address of FIT to boot, defaults to CONFIG_SYS_LOAD_ADDR. See notes below.
conf
configuration unit to boot (must be preceded by hash '#')
extra-conf
extra configuration to boot. This is supported only for additional
devicetree overlays to apply on the base device tree supplied by the first
configuration unit.
os_subimg
OS sub-image to boot (must be preceded by colon ':')
rd_subimg
ramdisk sub-image to boot. Use a hyphen '-' if there is no ramdisk but an
FDT is needed.
fdt_subimg
FDT sub-image to boot
See below for legacy boot. Booting using :doc:`../fit/index` is recommended.
Note on current image address
-----------------------------
When bootm is called without arguments, the image at current image address is
booted. The current image address is the address set most recently by a load
command, etc, and is by default equal to CONFIG_SYS_LOAD_ADDR. For example,
consider the following commands::
tftp 200000 /tftpboot/kernel
bootm
# Last command is equivalent to:
# bootm 200000
As shown above, with FIT the address portion of any argument
can be omitted. If <addr3> is omitted, then it is assumed that image at
<addr2> should be used. Similarly, when <addr2> is omitted, it is assumed that
image at <addr1> should be used. If <addr1> is omitted, it is assumed that the
current image address is to be used. For example, consider the following
commands::
tftp 200000 /tftpboot/uImage
bootm :kernel-1
# Last command is equivalent to:
# bootm 200000:kernel-1
tftp 200000 /tftpboot/uImage
bootm 400000:kernel-1 :ramdisk-1
# Last command is equivalent to:
# bootm 400000:kernel-1 400000:ramdisk-1
tftp 200000 /tftpboot/uImage
bootm :kernel-1 400000:ramdisk-1 :fdt-1
# Last command is equivalent to:
# bootm 200000:kernel-1 400000:ramdisk-1 400000:fdt-1
Legacy boot
-----------
U-Boot supports a legacy image format, enabled by `CONFIG_LEGACY_IMAGE_FORMAT`.
This is not recommended as it is quite limited and insecure. Use
:doc:`../fit/index` instead. It is documented here for old boards which still
use it.
Arguments are:
addr1
address of legacy image to boot. If the image includes a second component
(ramdisk) it is used as well, unless the second parameter is hyphen '-'.
addr2
address of legacy image to use as ramdisk
addr3
address of legacy image to use as FDT
Example syntax
--------------
This section provides various examples of possible usage::
1. bootm /* boot image at the current address, equivalent to 2,3,8 */
This is equivalent to cases 2, 3 or 8, depending on the type of image at
the current image address.
Boot method: see cases 2,3,8
Legacy uImage syntax
~~~~~~~~~~~~~~~~~~~~
::
2. bootm <addr1> /* single image at <addr1> */
Boot kernel image located at <addr1>.
Boot method: non-FDT
::
3. bootm <addr1> /* multi-image at <addr1> */
First and second components of the image at <addr1> are assumed to be a
kernel and a ramdisk, respectively. The kernel is booted with initrd loaded
with the ramdisk from the image.
Boot method: depends on the number of components at <addr1>, and on whether
U-Boot is compiled with OF support, which it should be.
==================== ======================== ========================
Configuration 2 components 3 components
(kernel, initrd) (kernel, initrd, fdt)
==================== ======================== ========================
#ifdef CONFIG_OF_* non-FDT FDT
#ifndef CONFIG_OF_* non-FDT non-FDT
==================== ======================== ========================
::
4. bootm <addr1> - /* multi-image at <addr1> */
Similar to case 3, but the kernel is booted without initrd. Second
component of the multi-image is irrelevant (it can be a dummy, 1-byte file).
Boot method: see case 3
::
5. bootm <addr1> <addr2> /* single image at <addr1> */
Boot kernel image located at <addr1> with initrd loaded with ramdisk
from the image at <addr2>.
Boot method: non-FDT
::
6. bootm <addr1> <addr2> <addr3> /* single image at <addr1> */
<addr1> is the address of a kernel image, <addr2> is the address of a
ramdisk image, and <addr3> is the address of a FDT binary blob. Kernel is
booted with initrd loaded with ramdisk from the image at <addr2>.
Boot method: FDT
::
7. bootm <addr1> - <addr3> /* single image at <addr1> */
<addr1> is the address of a kernel image and <addr3> is the address of
a FDT binary blob. Kernel is booted without initrd.
Boot method: FDT
FIT syntax
~~~~~~~~~~
::
8. bootm <addr1>
Image at <addr1> is assumed to contain a default configuration, which
is booted.
Boot method: FDT or non-FDT, depending on whether the default configuration
defines FDT
::
9. bootm [<addr1>]:<subimg1>
Similar to case 2: boot kernel stored in <subimg1> from the image at
address <addr1>.
Boot method: non-FDT
::
10. bootm [<addr1>]#<conf>[#<extra-conf[#...]]
Boot configuration <conf> from the image at <addr1>.
Boot method: FDT or non-FDT, depending on whether the configuration given
defines FDT
::
11. bootm [<addr1>]:<subimg1> [<addr2>]:<subimg2>
Equivalent to case 5: boot kernel stored in <subimg1> from the image
at <addr1> with initrd loaded with ramdisk <subimg2> from the image at
<addr2>.
Boot method: non-FDT
::
12. bootm [<addr1>]:<subimg1> [<addr2>]:<subimg2> [<addr3>]:<subimg3>
Equivalent to case 6: boot kernel stored in <subimg1> from the image
at <addr1> with initrd loaded with ramdisk <subimg2> from the image at
<addr2>, and pass FDT blob <subimg3> from the image at <addr3>.
Boot method: FDT
::
13. bootm [<addr1>]:<subimg1> [<addr2>]:<subimg2> <addr3>
Similar to case 12, the difference being that <addr3> is the address
of FDT binary blob that is to be passed to the kernel.
Boot method: FDT
::
14. bootm [<addr1>]:<subimg1> - [<addr3>]:<subimg3>
Equivalent to case 7: boot kernel stored in <subimg1> from the image
at <addr1>, without initrd, and pass FDT blob <subimg3> from the image at
<addr3>.
Boot method: FDT
15. bootm [<addr1>]:<subimg1> - <addr3>
Similar to case 14, the difference being that <addr3> is the address
of the FDT binary blob that is to be passed to the kernel.
Boot method: FDT
Example
-------
boot kernel "kernel-1" stored in a new uImage located at 200000::
bootm 200000:kernel-1
boot configuration "cfg-1" from a new uImage located at 200000::
bootm 200000#cfg-1
boot configuration "cfg-1" with extra "cfg-2" from a new uImage located
at 200000::
bootm 200000#cfg-1#cfg-2
boot "kernel-1" from a new uImage at 200000 with initrd "ramdisk-2" found in
some other new uImage stored at address 800000::
bootm 200000:kernel-1 800000:ramdisk-2
boot "kernel-2" from a new uImage at 200000, with initrd "ramdisk-1" and FDT
"fdt-1", both stored in some other new uImage located at 800000::
bootm 200000:kernel-1 800000:ramdisk-1 800000:fdt-1
boot kernel "kernel-2" with initrd "ramdisk-2", both stored in a new uImage
at address 200000, with a raw FDT blob stored at address 600000::
bootm 200000:kernel-2 200000:ramdisk-2 600000
boot kernel "kernel-2" from new uImage at 200000 with FDT "fdt-1" from the
same new uImage::
bootm 200000:kernel-2 - 200000:fdt-1
.. sectionauthor:: Bartlomiej Sieka <tur@semihalf.com>
.. sectionauthor:: Simon Glass <sjg@chromium.org>