global: Use proper project name U-Boot

Use proper project name in comments, Kconfig, readmes.

Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Acked-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Reviewed-by: Stefan Roese <sr@denx.de>
Reviewed-by: Qu Wenruo <wqu@suse.com>
Signed-off-by: Michal Simek <michal.simek@amd.com>
Link: https://lore.kernel.org/r/0dbdf0432405c1c38ffca55703b6737a48219e79.1684307818.git.michal.simek@amd.com

18 files changed, 27 insertions, 27 deletions

diff --git a/doc/README.pcap b/doc/README.pcap
index 8e30b93c66..10318ef0a9 100644
--- a/doc/README.pcap
+++ b/doc/README.pcap
@@ -1,6 +1,6 @@
 PCAP:
 
-U-boot supports live Ethernet packet capture in PCAP(2.4) format.
+U-Boot supports live Ethernet packet capture in PCAP(2.4) format.
 This is enabled by CONFIG_CMD_PCAP.
 
 The capture is stored on physical memory, and should be copied to
diff --git a/doc/README.s5p4418 b/doc/README.s5p4418
index ac724d08a0..8ec7b05fd2 100644
--- a/doc/README.s5p4418
+++ b/doc/README.s5p4418
@@ -38,7 +38,7 @@ The source code for (the used?) LUbuntu 16.04 can be found at [5].
 Links
 =====
 
-[1] FriendlyArm U-boot v2016.01:
+[1] FriendlyArm U-Boot v2016.01:
 
 https://github.com/friendlyarm/u-boot/tree/nanopi2-v2016.01
 
diff --git a/doc/SPL/README.spl-secure-boot b/doc/SPL/README.spl-secure-boot
index f2f8d78883..982fbec654 100644
--- a/doc/SPL/README.spl-secure-boot
+++ b/doc/SPL/README.spl-secure-boot
@@ -12,7 +12,7 @@ Methodology
 
 The SPL image is responsible for loading the next stage boot loader, which is
 the main u-boot image. For secure boot process on these platforms ROM verifies
-SPL image, so to continue chain of trust SPL image verifies U-boot image using
+SPL image, so to continue chain of trust SPL image verifies U-Boot image using
 spl_validate_uboot(). This function uses QorIQ Trust Architecture header
-(appended to U-boot image) to validate the U-boot binary just before passing
+(appended to U-Boot image) to validate the U-Boot binary just before passing
 control to it.
diff --git a/doc/board/amlogic/p201.rst b/doc/board/amlogic/p201.rst
index 28aae98d99..13b732fc7e 100644
--- a/doc/board/amlogic/p201.rst
+++ b/doc/board/amlogic/p201.rst
@@ -56,7 +56,7 @@ image but sources have been shared by Linux development contractor, Baylibre:
     $ make
     $ export FIPDIR=$PWD/fip
 
-Go back to mainline U-boot source tree then :
+Go back to mainline U-Boot source tree then :
 
 .. code-block:: bash
 
diff --git a/doc/board/amlogic/p212.rst b/doc/board/amlogic/p212.rst
index c1b73e83b1..a872f32f0f 100644
--- a/doc/board/amlogic/p212.rst
+++ b/doc/board/amlogic/p212.rst
@@ -50,7 +50,7 @@ the git tree published by the board vendor:
     $ make
     $ export FIPDIR=$PWD/fip
 
-Go back to mainline U-boot source tree then :
+Go back to mainline U-Boot source tree then :
 
 .. code-block:: bash
 
diff --git a/doc/board/amlogic/s400.rst b/doc/board/amlogic/s400.rst
index 59dda82375..205e7c38fa 100644
--- a/doc/board/amlogic/s400.rst
+++ b/doc/board/amlogic/s400.rst
@@ -56,7 +56,7 @@ image but sources have been shared by Linux development contractor, Baylibre:
     $ make
     $ export FIPDIR=$PWD/fip
 
-Go back to mainline U-boot source tree then :
+Go back to mainline U-Boot source tree then :
 
 .. code-block:: bash
 
diff --git a/doc/board/emulation/qemu-arm.rst b/doc/board/emulation/qemu-arm.rst
index 16f66388eb..b42d924cc6 100644
--- a/doc/board/emulation/qemu-arm.rst
+++ b/doc/board/emulation/qemu-arm.rst
@@ -54,7 +54,7 @@ Note that for some odd reason qemu-system-aarch64 needs to be explicitly
 told to use a 64-bit CPU or it will boot in 32-bit mode. The -nographic argument
 ensures that output appears on the terminal. Use Ctrl-A X to quit.
 
-Additional persistent U-boot environment support can be added as follows:
+Additional persistent U-Boot environment support can be added as follows:
 
 - Create envstore.img using qemu-img::
 
diff --git a/doc/board/nxp/ls1046ardb.rst b/doc/board/nxp/ls1046ardb.rst
index 35465d0061..49b4842b30 100644
--- a/doc/board/nxp/ls1046ardb.rst
+++ b/doc/board/nxp/ls1046ardb.rst
@@ -150,7 +150,7 @@ Then, launch openocd like::
 
     openocd -f u-boot.tcl
 
-You should see the U-boot SPL banner followed by the banner for U-Boot proper
+You should see the U-Boot SPL banner followed by the banner for U-Boot proper
 in the output of openocd. The CMSIS-DAP adapter is slow, so this can take a
 long time. If you don't see it, something has gone wrong. After a while, you
 should see the prompt. You can load an image using semihosting by running::
diff --git a/doc/board/nxp/mx6sabresd.rst b/doc/board/nxp/mx6sabresd.rst
index fe15ba7b79..c9869f4a73 100644
--- a/doc/board/nxp/mx6sabresd.rst
+++ b/doc/board/nxp/mx6sabresd.rst
@@ -53,7 +53,7 @@ This will generate the SPL and u-boot-dtb.img binaries.
 
 - Boot first from SD card as shown in the previous section
 
-In U-boot change the eMMC partition config::
+In U-Boot change the eMMC partition config::
 
    => mmc partconf 2 1 0 0
 
diff --git a/doc/board/rockchip/rockchip.rst b/doc/board/rockchip/rockchip.rst
index 99376fb54c..4c555e1c9c 100644
--- a/doc/board/rockchip/rockchip.rst
+++ b/doc/board/rockchip/rockchip.rst
@@ -333,12 +333,12 @@ Note:
 
 Unlike later SoC models the rk3066 BootROM doesn't have SDMMC support.
 If all other boot options fail then it enters into a BootROM mode on the USB OTG port.
-This method loads TPL/SPL on NAND with U-boot and kernel on SD card.
+This method loads TPL/SPL on NAND with U-Boot and kernel on SD card.
 
 SD Card
 ^^^^^^^
 
-U-boot expects a GPT partition map and a boot directory structure with files on the SD card.
+U-Boot expects a GPT partition map and a boot directory structure with files on the SD card.
 
 .. code-block:: none
 
@@ -363,7 +363,7 @@ Boot partition:
         zImage
         rk3066a-mk808.dtb
 
-To write a U-boot image to the SD card (assumed to be /dev/sda):
+To write a U-Boot image to the SD card (assumed to be /dev/sda):
 
 .. code-block:: bash
 
diff --git a/doc/board/sifive/unmatched.rst b/doc/board/sifive/unmatched.rst
index de2aab59bb..c515949066 100644
--- a/doc/board/sifive/unmatched.rst
+++ b/doc/board/sifive/unmatched.rst
@@ -558,7 +558,7 @@ for partitions one through three respectively.
 	    --new=3:10280:10535 --change-name=3:env   --typecode=3:3DE21764-95BD-54BD-A5C3-4ABE786F38A8 \
 	    /dev/mtdblock0
 
-Write U-boot SPL and U-boot to their partitions.
+Write U-Boot SPL and U-Boot to their partitions.
 
 .. code-block:: none
 
diff --git a/doc/board/st/stm32mp1.rst b/doc/board/st/stm32mp1.rst
index c0b1daa041..63b44776ff 100644
--- a/doc/board/st/stm32mp1.rst
+++ b/doc/board/st/stm32mp1.rst
@@ -345,7 +345,7 @@ Build Procedure
         - BL33=u-boot-nodtb.bin
         - BL33_CFG=u-boot.dtb
 
-     You can also update a existing FIP after U-boot compilation with fiptool,
+     You can also update a existing FIP after U-Boot compilation with fiptool,
      a tool provided by TF-A_::
 
      # fiptool update --nt-fw u-boot-nodtb.bin --hw-config u-boot.dtb fip-stm32mp157c-ev1.bin
diff --git a/doc/board/xen/xenguest_arm64.rst b/doc/board/xen/xenguest_arm64.rst
index 1327f88f99..e9bdaf7ffb 100644
--- a/doc/board/xen/xenguest_arm64.rst
+++ b/doc/board/xen/xenguest_arm64.rst
@@ -6,7 +6,7 @@ Xen guest ARM64 board
 This board specification
 ------------------------
 
-This board is to be run as a virtual Xen [1] guest with U-boot as its primary
+This board is to be run as a virtual Xen [1] guest with U-Boot as its primary
 bootloader. Xen is a type 1 hypervisor that allows multiple operating systems
 to run simultaneously on a single physical server. Xen is capable of running
 virtual machines in both full virtualization and para-virtualization (PV)
@@ -16,7 +16,7 @@ Paravirtualized drivers are a special type of device drivers that are used in
 a guest system in the Xen domain and perform I/O operations using a special
 interface provided by the virtualization system and the host system.
 
-Xen support for U-boot is implemented by introducing a new Xen guest ARM64
+Xen support for U-Boot is implemented by introducing a new Xen guest ARM64
 board and porting essential drivers from MiniOS [3] as well as some of the work
 previously done by NXP [4]:
 
@@ -39,7 +39,7 @@ previously done by NXP [4]:
 Board limitations
 -----------------
 
-1. U-boot runs without MMU enabled at the early stages.
+1. U-Boot runs without MMU enabled at the early stages.
    According to Xen on ARM ABI (xen/include/public/arch-arm.h): all memory
    which is shared with other entities in the system (including the hypervisor
    and other guests) must reside in memory which is mapped as Normal Inner
@@ -54,14 +54,14 @@ Board limitations
 2. No serial console until MMU is up.
    Because data cache maintenance is required until the MMU setup the
    early/debug serial console is not implemented. Therefore, we do not have
-   usual prints like U-boot’s banner etc. until the serial driver is
+   usual prints like U-Boot’s banner etc. until the serial driver is
    initialized.
 
 3. Single RAM bank supported.
    If a Xen guest is given much memory it is possible that Xen allocates two
    memory banks for it. The first one is allocated under 4GB address space and
    in some cases may represent the whole guest’s memory. It is assumed that
-   U-boot most likely won’t require high memory bank for its work andlaunching
+   U-Boot most likely won’t require high memory bank for its work andlaunching
    OS, so it is enough to take the first one.
 
 
diff --git a/doc/develop/driver-model/bind.rst b/doc/develop/driver-model/bind.rst
index b19661b5fe..0d0d40734c 100644
--- a/doc/develop/driver-model/bind.rst
+++ b/doc/develop/driver-model/bind.rst
@@ -7,7 +7,7 @@ Binding/unbinding a driver
 This document aims to describe the bind and unbind commands.
 
 For debugging purpose, it should be useful to bind or unbind a driver from
-the U-boot command line.
+the U-Boot command line.
 
 The unbind command calls the remove device driver callback and unbind the
 device from its driver.
diff --git a/doc/develop/driver-model/fs_firmware_loader.rst b/doc/develop/driver-model/fs_firmware_loader.rst
index b0823700a9..149b8b436e 100644
--- a/doc/develop/driver-model/fs_firmware_loader.rst
+++ b/doc/develop/driver-model/fs_firmware_loader.rst
@@ -92,9 +92,9 @@ For example of getting DT phandle from /chosen and creating instance:
 	if (ret)
 		return ret;
 
-Firmware loader driver is also designed to support U-boot environment
+Firmware loader driver is also designed to support U-Boot environment
 variables, so all these data from FDT can be overwritten
-through the U-boot environment variable during run time.
+through the U-Boot environment variable during run time.
 
 For examples:
 
@@ -110,7 +110,7 @@ fw_ubi_volume:
 When above environment variables are set, environment values would be
 used instead of data from FDT.
 The benefit of this design allows user to change storage attribute data
-at run time through U-boot console and saving the setting as default
+at run time through U-Boot console and saving the setting as default
 environment values in the storage for the next power cycle, so no
 compilation is required for both driver and FDT.
 
diff --git a/doc/develop/uefi/uefi.rst b/doc/develop/uefi/uefi.rst
index ffe25ca231..ef0987c355 100644
--- a/doc/develop/uefi/uefi.rst
+++ b/doc/develop/uefi/uefi.rst
@@ -330,7 +330,7 @@ bit in OsIndications variable with
 
     => setenv -e -nv -bs -rt -v OsIndications =0x0000000000000004
 
-Since U-boot doesn't currently support SetVariable at runtime, its value
+Since U-Boot doesn't currently support SetVariable at runtime, its value
 won't be taken over across the reboot. If this is the case, you can skip
 this feature check with the Kconfig option (CONFIG_EFI_IGNORE_OSINDICATIONS)
 set.
diff --git a/doc/usage/cmd/source.rst b/doc/usage/cmd/source.rst
index 61a4505909..a5c5204a28 100644
--- a/doc/usage/cmd/source.rst
+++ b/doc/usage/cmd/source.rst
@@ -161,7 +161,7 @@ The boot scripts (boot.scr) is created with:
 
     mkimage -T script -n 'Test script' -d boot.txt boot.scr
 
-The script can be execute in U-boot like this:
+The script can be execute in U-Boot like this:
 
 .. code-block::
 
diff --git a/doc/usage/dfu.rst b/doc/usage/dfu.rst
index ed47ff561e..68cacbbef6 100644
--- a/doc/usage/dfu.rst
+++ b/doc/usage/dfu.rst
@@ -9,7 +9,7 @@ Overview
 The Device Firmware Upgrade (DFU) allows to download and upload firmware
 to/from U-Boot connected over USB.
 
-U-boot follows the Universal Serial Bus Device Class Specification for
+U-Boot follows the Universal Serial Bus Device Class Specification for
 Device Firmware Upgrade Version 1.1 the USB forum (DFU v1.1 in www.usb.org).
 
 U-Boot implements this DFU capability (CONFIG_DFU) with the command dfu