armv8: fsl-layerscape: Updating entries in Serdes Table

[u-boot] / doc / README.distro

diff --git a/doc/README.distro b/doc/README.distro
index dd0f1c7b6afa812bb9bfa9830dcd0d40a6c9365f..e1b72161521fa8728fde85955ef102b81e19ae22 100644 (file)
--- a/doc/README.distro
+++ b/doc/README.distro
@@ -1,6 +1,7 @@
 /*
  * (C) Copyright 2014 Red Hat Inc.
  * Copyright (c) 2014-2015, NVIDIA CORPORATION.  All rights reserved.
 /*
  * (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+
  */
  *
  * SPDX-License-Identifier:     GPL-2.0+
  */


@@ -27,7 +28,7 @@ decoupling distro install/boot logic from any knowledge of the bootloader.
 
 This model assumes that boards will load boot configuration files from a
 regular storage mechanism (eMMC, SD card, USB Disk, SATA disk, etc.) with
 
 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.
 
 storage model are outside the scope of this document, and may still need
 board-specific installer/boot-configuration support in a distro.
 


@@ -36,9 +37,9 @@ that contains U-Boot, and that the user has somehow installed U-Boot to this
 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
 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
 -----------------------
 
 Locating Bootable Disks
 -----------------------


@@ -60,7 +61,7 @@ any other bootloader) will find those boot files and execute them. This is
 conceptually identical to creating a grub2 configuration file on a desktop
 PC.
 
 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
 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


@@ -237,12 +238,12 @@ kernel_addr_r:
   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
   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.
 
   have to copy itself somewhere else first before decompression.
 
   A size of 16MB for the kernel is likely adequate.
 

-pxe_addr_r:
+pxefile_addr_r:

 
   Mandatory. The location in RAM where extlinux.conf will be loaded to prior
   to processing.
 
   Mandatory. The location in RAM where extlinux.conf will be loaded to prior
   to processing.


@@ -339,3 +340,64 @@ scan_dev_for_scripts:
 
   If you want to disable boot.scr on all disks, set the value to something
   innocuous, e.g. setenv scan_dev_for_scripts true.
 
   If you want to disable boot.scr on all disks, set the value to something
   innocuous, e.g. setenv scan_dev_for_scripts true.

+
+boot_net_usb_start:
+
+  If you want to prevent USB enumeration by distro boot commands which execute
+  network operations, set the value to something innocuous, e.g. setenv
+  boot_net_usb_start true. This would be useful if you know your Ethernet
+  device is not attached to USB, and you wish to increase boot speed by
+  avoiding unnecessary actions.
+
+boot_net_pci_enum:
+
+  If you want to prevent PCI enumeration by distro boot commands which execute
+  network operations, set the value to something innocuous, e.g. setenv
+  boot_net_pci_enum true. This would be useful if you know your Ethernet
+  device is not attached to PCI, and you wish to increase boot speed by
+  avoiding unnecessary actions.
+
+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.