/*
* (C) Copyright 2014 Red Hat Inc.
* Copyright (c) 2014-2015, NVIDIA CORPORATION. All rights reserved.
+ * Copyright (C) 2015 K. Merker <merker@debian.org>
*
* SPDX-License-Identifier: GPL-2.0+
*/
This model assumes that boards will load boot configuration files from a
regular storage mechanism (eMMC, SD card, USB Disk, SATA disk, etc.) with
-a standard partitioning scheme (MBR, GPT). Boards that cannnot support this
+a standard partitioning scheme (MBR, GPT). Boards that cannot support this
storage model are outside the scope of this document, and may still need
board-specific installer/boot-configuration support in a distro.
flash before running the distro installer. Even on boards that do not conform
to this aspect of the model, the extent of the board-specific support in the
distro installer logic would be to install a board-specific U-Boot package to
-the boot partition partition during installation. This distro-supplied U-Boot
-can still implement the same features as on any other board, and hence the
-distro's boot configuration file generation logic can still be board-agnostic.
+the boot partition during installation. This distro-supplied U-Boot can still
+implement the same features as on any other board, and hence the distro's boot
+configuration file generation logic can still be board-agnostic.
Locating Bootable Disks
-----------------------
conceptually identical to creating a grub2 configuration file on a desktop
PC.
-Note that in the absense of any partition that is explicitly marked bootable,
+Note that in the absence of any partition that is explicitly marked bootable,
U-Boot falls back to searching the first valid partition of a disk for boot
configuration files. Other bootloaders are recommended to do the same, since
I believe that partition table bootable flags aren't so commonly used outside
The kernel should be located within the first 128M of RAM in order for the
kernel CONFIG_AUTO_ZRELADDR option to work, which is likely enabled on any
distro kernel. Since the kernel will decompress itself to 0x8000 after the
- start of RAM, kernel_addr_rshould not overlap that area, or the kernel will
+ start of RAM, kernel_addr_r should not overlap that area, or the kernel will
have to copy itself somewhere else first before decompression.
A size of 16MB for the kernel is likely adequate.
If you want to disable boot.scr on all disks, set the value to something
innocuous, e.g. setenv scan_dev_for_scripts true.
+
+
+Interactively booting from a specific device at the u-boot prompt
+=================================================================
+
+For interactively booting from a user-selected device at the u-boot command
+prompt, the environment provides predefined bootcmd_<target> variables for
+every target defined in boot_targets, which can be run be the user.
+
+If the target is a storage device, the format of the target is always
+<device type><device number>, e.g. mmc0. Specifying the device number is
+mandatory for storage devices, even if only support for a single instance
+of the storage device is actually implemented.
+
+For network targets (dhcp, pxe), only the device type gets specified;
+they do not have a device number.
+
+Examples:
+
+ - run bootcmd_usb0
+ boots from the first USB mass storage device
+
+ - run bootcmd_mmc1
+ boots from the second MMC device
+
+ - run bootcmd_pxe
+ boots by tftp using a pxelinux.cfg
+
+The list of possible targets consists of:
+
+- network targets
+ * dhcp
+ * pxe
+
+- storage targets (to which a device number must be appended)
+ * mmc
+ * sata
+ * scsi
+ * ide
+ * usb
+
+Other *boot* variables than the ones defined above are only for internal use
+of the boot environment and are not guaranteed to exist or work in the same
+way in future u-boot versions. In particular the <device type>_boot
+variables (e.g. mmc_boot, usb_boot) are a strictly internal implementation
+detail and must not be used as a public interface.
projects / karo-tx-uboot.git / blobdiff