global: Use proper project name U-Boot (next2)

Use proper project name in README, rst and comment.
Done in connection to commit bb922ca3eb4b ("global: Use proper project name
U-Boot (next)").

Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Alexander Graf <graf@csgraf.de> (ppce500)
Signed-off-by: Michal Simek <michal.simek@amd.com>
Link: https://lore.kernel.org/r/536af05e7061982f15b668e87f941cdabfa25392.1694157084.git.michal.simek@amd.com

diff --git a/board/cobra5272/README b/board/cobra5272/README
index 11abcfacdb6e9f2e05b3b6f9db903930ec04f4c6..0b07148b73a3ab1383f0c9f180349f5e7986cb51 100644 (file)
--- a/board/cobra5272/README
+++ b/board/cobra5272/README
@@ -1,6 +1,6 @@
 File:          README.COBRA5272
 Author:                Florian Schlote for Sentec elektronik (linux@sentec-elektronik.de)
-Contents:      This is the README of u-boot (Universal bootloader) for our
+Contents:      This is the README of U-Boot (Universal bootloader) for our
                COBRA5272 board.
 Version:       v01.00
 Date:          Tue Mar 30 00:28:33 CEST 2004
@@ -31,7 +31,7 @@ Please refer to u-boot README (general info, u-boot-x-x-x/README),
 to u-boot-x-x-x/board/cobra5272/README and
 to the comments in u-boot-x-x-x/include/configs/cobra5272.h
 
-Configuring u-boot is done by commenting/uncommenting preprocessor defines.
+Configuring U-Boot is done by commenting/uncommenting preprocessor defines.
 
 Default configuration is
 
@@ -48,10 +48,10 @@ Default configuration is
 
 
 #-----------------------------------
-# u-boot FLASH version & RAM version
+# U-Boot FLASH version & RAM version
 #-----------------------------------
 
-The u-boot bootloader for Coldfire processors can be configured
+The U-Boot bootloader for Coldfire processors can be configured
 
        1. as a standalone bootloader residing in flash & relocating itself to RAM on
        startup automatically => "FLASH version"
@@ -60,7 +60,7 @@ The u-boot bootloader for Coldfire processors can be configured
        prestage bootloader ("chainloading") & is running only from the RAM address it
        is linked to => "RAM version"
 
-       This version may be very helpful when installing u-boot for the first time
+       This version may be very helpful when installing U-Boot for the first time
        since it can be used to make available s. th. like a "bootstrap
        mechanism".
 
@@ -71,7 +71,7 @@ How to build the different images:
 Flash version
 ------------------------------
 
-Compile u-boot
+Compile U-Boot
 
 in dir ./u-boot-x-x-x/
 
@@ -81,14 +81,14 @@ please first check:
 
                CONFIG_MONITOR_IS_IN_RAM has to be not present in the file
 
-       => u-boot as single bootloader starting from flash
+       => U-Boot as single bootloader starting from flash
 
 
        in configs/cobra5272_defconfig CONFIG_TEXT_BASE should be
 
                CONFIG_TEXT_BASE=0xffe00000
 
-       => linking address for u-boot as single bootloader stored in flash
+       => linking address for U-Boot as single bootloader stored in flash
 
 then:
 
@@ -116,7 +116,7 @@ please modify the settings:
 
                CONFIG_MONITOR_IS_IN_RAM=y
 
-       => u-boot as RAM version, chainloaded by another bootloader or using bdm cable
+       => U-Boot as RAM version, chainloaded by another bootloader or using bdm cable
 
 
        in configs/cobra5272_defconfig CONFIG_TEXT_BASE should be

diff --git a/board/emulation/qemu-ppce500/qemu-ppce500.c b/board/emulation/qemu-ppce500/qemu-ppce500.c
index 7ca8773b17e5a73ed6839989a2cfc060583b11af..221361691c15b9cf987b0c8ae48873fb18b27427 100644 (file)
--- a/board/emulation/qemu-ppce500/qemu-ppce500.c
+++ b/board/emulation/qemu-ppce500/qemu-ppce500.c
@@ -320,7 +320,7 @@ ulong get_bus_freq(ulong dummy)
 int cpu_numcores(void)
 {
        /*
-        * The QEMU u-boot target only needs to drive the first core,
+        * The QEMU U-Boot target only needs to drive the first core,
         * spinning and device tree nodes get driven by QEMU itself
         */
        return 1;

diff --git a/doc/board/xilinx/zynq.rst b/doc/board/xilinx/zynq.rst
index 438912fe42c289de096e13db2ffb3c2c0330dd8c..76d67bd62ee9f293dd2e636e68b3156faaf4b593 100644 (file)
--- a/doc/board/xilinx/zynq.rst
+++ b/doc/board/xilinx/zynq.rst
@@ -83,7 +83,7 @@ Mainline status
 ---------------
 
 - Added basic board configurations support.
-- Added zynq u-boot bsp code - arch/arm/mach-zynq
+- Added zynq U-Boot bsp code - arch/arm/mach-zynq
 - Added zynq boards named - zc70x, zed, microzed, zc770_xm010/xm011/xm012/xm013
 - Added zynq drivers:
 

diff --git a/doc/board/xilinx/zynqmp-r5.rst b/doc/board/xilinx/zynqmp-r5.rst
index 2cd368b0308e32cfb34e07748a339198238965ca..266d07d1193f1cbea5d487b97e854055daef2f52 100644 (file)
--- a/doc/board/xilinx/zynqmp-r5.rst
+++ b/doc/board/xilinx/zynqmp-r5.rst
@@ -26,7 +26,7 @@ configure and build armv7 toolchain::
 Notes
 ^^^^^
 
-Output fragment is u-boot.
+Output fragment is U-Boot.
 
 Loading
 -------
@@ -38,7 +38,7 @@ Bootgen
 ^^^^^^^
 
 The first way is to use Xilinx FSBL (First stage
-bootloader) to load u-boot and start it. The following bif can be used for boot
+bootloader) to load U-Boot and start it. The following bif can be used for boot
 image generation via Xilinx bootgen utility::
 
 

diff --git a/doc/imx/mkimage/imximage.txt b/doc/imx/mkimage/imximage.txt
index f2cf23c5dab818a4e470582848c02f46b1f8288d..fa4e486661c262b3a2b437334cd072f8041b4014 100644 (file)
--- a/doc/imx/mkimage/imximage.txt
+++ b/doc/imx/mkimage/imximage.txt
@@ -213,7 +213,7 @@ Disk identifier: 0xb712a870
        Device Boot      Start         End      Blocks   Id  System
 /dev/mmcblk0p1              3          16      112455   83  Linux
 
-I have set 100MB, leaving the first 2 sectors free. I will copy u-boot
+I have set 100MB, leaving the first 2 sectors free. I will copy U-Boot
 there.
 
 8. Write the partition table and exit.

diff --git a/doc/usage/environment.rst b/doc/usage/environment.rst
index c6439dde6689391ad1e58b8c58f405a7fab9f849..c57b717caaf3f7a948b4ae0ff41b867547fda433 100644 (file)
--- a/doc/usage/environment.rst
+++ b/doc/usage/environment.rst
@@ -216,7 +216,7 @@ fdt_high
     0xffffffffffffffff (64-bit machines) then
     the fdt will not be copied at all on boot.  For this
     to work it must reside in writable memory, have
-    sufficient padding on the end of it for u-boot to
+    sufficient padding on the end of it for U-Boot to
     add the information it needs into it, and the memory
     must be accessible by the kernel. This usage is strongly discouraged
     however as it also stops U-Boot from ensuring the device tree starting

diff --git a/doc/usage/semihosting.rst b/doc/usage/semihosting.rst
index 6a280b455e0c99dd63c077f0c8d71f06eafa6eba..9303a6364d5d2fc97d95d1359f4a61bc224d52f3 100644 (file)
--- a/doc/usage/semihosting.rst
+++ b/doc/usage/semihosting.rst
@@ -23,7 +23,7 @@ eMMC or other NV media are available.
 There are two main ARM virtual Fixed Virtual Platform (FVP) models,
 `Versatile Express (VE) FVP and BASE FVP
 <http://www.arm.com/products/tools/models/fast-models/foundation-model.php>`_.
-The initial vexpress64 u-boot board created here runs on the VE virtual
+The initial vexpress64 U-Boot board created here runs on the VE virtual
 platform using the license-free Foundation_v8 simulator. Fortunately,
 the Foundation_v8 simulator also supports the BASE_FVP model which
 companies can purchase licenses for and contain much more functionality.