Use correct spelling of "U-Boot"
Correct spelling of "U-Boot" shall be used in all written text
(documentation, comments in source files etc.).
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Heiko Schocher <hs@denx.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Minkyu Kang <mk7.kang@samsung.com>
diff --git a/doc/README.440-DDR-performance b/doc/README.440-DDR-performance
index 17bc747..66b97bc 100644
--- a/doc/README.440-DDR-performance
+++ b/doc/README.440-DDR-performance
@@ -9,7 +9,7 @@
----------------------------------------
-SDRAM0_CFG0[PMU] = 1 (U-boot default for Bamboo, Yosemite and Yellowstone)
+SDRAM0_CFG0[PMU] = 1 (U-Boot default for Bamboo, Yosemite and Yellowstone)
----------------------------------------
Stream benchmark results
-------------------------------------------------------------
diff --git a/doc/README.arm64 b/doc/README.arm64
index f32108f..de669cb 100644
--- a/doc/README.arm64
+++ b/doc/README.arm64
@@ -1,20 +1,20 @@
-U-boot for arm64
+U-Boot for arm64
Summary
=======
-No hardware platform of arm64 is available now. The u-boot is
+No hardware platform of arm64 is available now. The U-Boot is
simulated on Foundation Model and Fast Model for ARMv8.
Notes
=====
-1. Currenly, u-boot run at the highest exception level processor
+1. Currenly, U-Boot run at the highest exception level processor
supported and jump to EL2 or optionally EL1 before enter OS.
-2. U-boot for arm64 is compiled with AArch64-gcc. AArch64-gcc
+2. U-Boot for arm64 is compiled with AArch64-gcc. AArch64-gcc
use rela relocation format, a tool(tools/relocate-rela) by Scott Wood
is used to encode the initial addend of rela to u-boot.bin. After running,
- the u-boot will be relocated to destination again.
+ the U-Boot will be relocated to destination again.
3. Fdt should be placed at a 2-megabyte boundary and within the first 512
megabytes from the start of the kernel image. So, fdt_high should be
diff --git a/doc/README.b4860qds b/doc/README.b4860qds
index 6fcc3bd..889c8a9 100644
--- a/doc/README.b4860qds
+++ b/doc/README.b4860qds
@@ -227,15 +227,15 @@
NOR Flash memory Map on B4860 and B4420QDS
------------------------------------------
Start End Definition Size
-0xEFF40000 0xEFFFFFFF u-boot (current bank) 768KB
-0xEFF20000 0xEFF3FFFF u-boot env (current bank) 128KB
+0xEFF40000 0xEFFFFFFF U-Boot (current bank) 768KB
+0xEFF20000 0xEFF3FFFF U-Boot env (current bank) 128KB
0xEFF00000 0xEFF1FFFF FMAN Ucode (current bank) 128KB
0xEF300000 0xEFEFFFFF rootfs (alternate bank) 12MB
0xEE800000 0xEE8FFFFF device tree (alternate bank) 1MB
0xEE020000 0xEE6FFFFF Linux.uImage (alternate bank) 6MB+896KB
0xEE000000 0xEE01FFFF RCW (alternate bank) 128KB
-0xEDF40000 0xEDFFFFFF u-boot (alternate bank) 768KB
-0xEDF20000 0xEDF3FFFF u-boot env (alternate bank) 128KB
+0xEDF40000 0xEDFFFFFF U-Boot (alternate bank) 768KB
+0xEDF20000 0xEDF3FFFF U-Boot env (alternate bank) 128KB
0xEDF00000 0xEDF1FFFF FMAN ucode (alternate bank) 128KB
0xED300000 0xEDEFFFFF rootfs (current bank) 12MB
0xEC800000 0xEC8FFFFF device tree (current bank) 1MB
@@ -246,7 +246,7 @@
--------------------------------------------------------------
The below commands apply to both B4860QDS and B4420QDS.
-1. U-boot environment variable hwconfig
+1. U-Boot environment variable hwconfig
The default hwconfig is:
hwconfig=fsl_ddr:ctlr_intlv=null,bank_intlv=cs0_cs1;usb1:
dr_mode=host,phy_type=ulpi
@@ -267,7 +267,7 @@
4. To change personality of board
For changing personality from B4860 to B4420
1)Boot from vbank0
- 2)Flash vbank2 with b4420 rcw and u-boot
+ 2)Flash vbank2 with b4420 rcw and U-Boot
3)Give following commands to uboot prompt
=> mw.b ffdf0040 0x30;
=> mw.b ffdf0010 0x00;
@@ -309,7 +309,7 @@
When using [DEFAULT] RCW, which including 2 * 1G SGMII on board and 2 * 1G
SGMII on SGMII riser card.
- Under U-boot these network interfaces are recognized as:
+ Under U-Boot these network interfaces are recognized as:
FM1@DTSEC3, FM1@DTSEC4, FM1@DTSEC5 and FM1@DTSEC6.
On Linux the interfaces are renamed as:
@@ -322,7 +322,7 @@
Serdes protocosl tested:
0x18, 0x9e (serdes1, serdes2)
- Under U-boot these network interfaces are recognized as:
+ Under U-Boot these network interfaces are recognized as:
FM1@DTSEC3, FM1@DTSEC4 and e1000#0.
On Linux the interfaces are renamed as:
@@ -333,8 +333,8 @@
----------------------------------
PBL initialise the internal SRAM and copy SPL(160KB) in SRAM.
SPL further initialise DDR using SPD and environment variables and copy
-u-boot(768 KB) from flash to DDR.
-Finally SPL transer control to u-boot for futher booting.
+U-Boot(768 KB) from flash to DDR.
+Finally SPL transer control to U-Boot for futher booting.
SPL has following features:
- Executes within 256K
@@ -355,12 +355,12 @@
-----------------------------------------------
STACK | 0xFFFD8000 (22KB) |
-----------------------------------------------
- U-boot SPL | 0xFFFD8000 (160KB) |
+ U-Boot SPL | 0xFFFD8000 (160KB) |
-----------------------------------------------
NAND Flash memory Map on B4860 and B4420QDS
------------------------------------------
Start End Definition Size
-0x000000 0x0FFFFF u-boot 1MB
-0x140000 0x15FFFF u-boot env 128KB
+0x000000 0x0FFFFF U-Boot 1MB
+0x140000 0x15FFFF U-Boot env 128KB
0x1A0000 0x1BFFFF FMAN Ucode 128KB
diff --git a/doc/README.clang b/doc/README.clang
index fe36909..7ce5ae4 100644
--- a/doc/README.clang
+++ b/doc/README.clang
@@ -1,4 +1,4 @@
-The biggest problem when trying to compile U-boot with clang is that
+The biggest problem when trying to compile U-Boot with clang is that
almost all archs rely on storing gd in a global register and clang user
manual states: "clang does not support global register variables; this
is unlikely to be implemented soon because it requires additional LLVM
@@ -17,9 +17,9 @@
in the ARM world, since crt0.S takes care of this. These assignments
can be avoided by changing the init calls but this is not in mainline yet.
-NOTE: without the -mllvm -arm-use-movt=0 flags u-boot will compile
+NOTE: without the -mllvm -arm-use-movt=0 flags U-Boot will compile
fine, but llvm might hardcode addresses in movw / movt pairs, which
-cannot be relocated and u-boot will fail at runtime.
+cannot be relocated and U-Boot will fail at runtime.
Debian (based)
--------------
@@ -45,7 +45,7 @@
gmake CC="clang -target arm-freebsd-eabi --sysroot /usr/arm-freebsd -no-integrated-as -mllvm -arm-use-movt=0" rpi_defconfig
gmake CC="clang -target arm-freebsd-eabi --sysroot /usr/arm-freebsd -no-integrated-as -mllvm -arm-use-movt=0" -j8
-Given that u-boot will default to gcc, above commands can be
+Given that U-Boot will default to gcc, above commands can be
simplified with a simple wrapper script, listed below.
/usr/local/bin/arm-gnueabi-freebsd-gcc
diff --git a/doc/README.fec_mxc b/doc/README.fec_mxc
index 30e05da..ed7e47d 100644
--- a/doc/README.fec_mxc
+++ b/doc/README.fec_mxc
@@ -1,4 +1,4 @@
-U-boot config options used in fec_mxc.c
+U-Boot config options used in fec_mxc.c
CONFIG_FEC_MXC
Selects fec_mxc.c to be compiled into u-boot. Can read out the
diff --git a/doc/README.fsl-ddr b/doc/README.fsl-ddr
index 1243a12..cd71ec8 100644
--- a/doc/README.fsl-ddr
+++ b/doc/README.fsl-ddr
@@ -61,7 +61,7 @@
"hwconfig=fsl_ddr:ctlr_intlv=bank" \
......
-2. Run u-boot "setenv" command to configure the memory interleaving mode.
+2. Run U-Boot "setenv" command to configure the memory interleaving mode.
Either numerical or string value is accepted.
# disable memory controller interleaving
@@ -125,7 +125,7 @@
Memory testing options for mpc85xx
==================================
-1. Memory test can be done once U-boot prompt comes up using mtest, or
+1. Memory test can be done once U-Boot prompt comes up using mtest, or
2. Memory test can be done with Power-On-Self-Test function, activated at
compile time.
@@ -267,7 +267,7 @@
be activated by setting the environment variable "ddr_interactive" to any
value. (The value of ddr_interactive may have a meaning in the future, but,
for now, the presence of the variable will cause the debugger to run.) Once
-activated, U-boot will show the prompt "FSL DDR>" before enabling the DDR
+activated, U-Boot will show the prompt "FSL DDR>" before enabling the DDR
controller. The available commands are printed by typing "help".
Another way to enter the interactive DDR debugger without setting the
@@ -275,7 +275,7 @@
process. To save booting time, no additional delay is added, so the window
to send the key press is very short -- basically, it is the time before the
memory controller code starts to run. For example, when rebooting from
-within u-boot, the user must press 'd' IMMEDIATELY after hitting enter to
+within U-Boot, the user must press 'd' IMMEDIATELY after hitting enter to
initiate a 'reset' command. In case of power on/reset, the user can hold
down the 'd' key while applying power or hitting the board's reset button.
@@ -341,7 +341,7 @@
no argument - print a list of all commands
go
- no argument - program memory controller(s) and continue with U-boot
+ no argument - program memory controller(s) and continue with U-Boot
Examples of debugging flow
diff --git a/doc/README.imx6 b/doc/README.imx6
index 7c9a4ac..1823fb2 100644
--- a/doc/README.imx6
+++ b/doc/README.imx6
@@ -37,7 +37,7 @@
bank = 4
word = 2
-And the U-boot command would be:
+And the U-Boot command would be:
=> fuse read 4 2
Reading bank 4:
@@ -58,7 +58,7 @@
bank = 4
word = 3
-And the U-boot command would be:
+And the U-Boot command would be:
=> fuse read 4 3
Reading bank 4:
diff --git a/doc/README.m68k b/doc/README.m68k
index c85febc..9d5c08f 100644
--- a/doc/README.m68k
+++ b/doc/README.m68k
@@ -17,7 +17,7 @@
Bernhard Kuhn ported U-Boot 0.4.0 to the Motorola Coldfire
architecture. The patches of Bernhard support the MCF5272 and
MCF5282. A great disadvantage of these patches was that they needed
-a pre-bootloader to start u-boot. Because of this, a new port was
+a pre-bootloader to start U-Boot. Because of this, a new port was
created which no longer needs a first stage booter.
Although this port is intended to cover all M68k processors, only
@@ -53,8 +53,8 @@
U-Boot Memory Map:
------------------
-0xffe00000 - 0xffe3ffff u-boot
-0xffe04000 - 0xffe05fff environment (embedded in u-boot!)
+0xffe00000 - 0xffe3ffff U-Boot
+0xffe04000 - 0xffe05fff environment (embedded in U-Boot!)
0xffe40000 - 0xffffffff free for linux/applications
@@ -65,13 +65,13 @@
To configure the board, type: make M5272C3_config
At the moment the code isn't fully implemented and still needs a pre-loader!
-The preloader must initialize the processor and then start u-boot. The board
+The preloader must initialize the processor and then start U-Boot. The board
must be configured for a pre-loader (see 4.1)
For the preloader, please see
http://mailman.uclinux.org/pipermail/uclinux-dev/2003-December/023384.html
-U-boot is configured to run at 0x20000 at default. This can be configured by
+U-Boot is configured to run at 0x20000 at default. This can be configured by
change CONFIG_SYS_TEXT_BASE in board/m5282evb/config.mk and CONFIG_SYS_MONITOR_BASE in
include/configs/M5282EVB.h.
@@ -91,10 +91,10 @@
4.1 Configuration to use a pre-loader
-------------------------------------
-If u-boot should be loaded to RAM and started by a pre-loader
+If U-Boot should be loaded to RAM and started by a pre-loader
CONFIG_MONITOR_IS_IN_RAM must be defined. If it is defined the
initial vector table and basic processor initialization will not
-be compiled in. The start address of u-boot must be adjusted in
+be compiled in. The start address of U-Boot must be adjusted in
the boards config header file (CONFIG_SYS_MONITOR_BASE) and Makefile
(CONFIG_SYS_TEXT_BASE) to the load address.
@@ -105,7 +105,7 @@
CONFIG_M5272 -- defined for all Motorola MCF5272 CPUs
CONFIG_MONITOR_IS_IN_RAM
- -- defined if u-boot is loaded by a pre-loader
+ -- defined if U-Boot is loaded by a pre-loader
CONFIG_SYS_MBAR -- defines the base address of the MCF5272 configuration registers
CONFIG_SYS_INIT_RAM_ADDR
@@ -130,7 +130,7 @@
CONFIG_M5282 -- defined for all Motorola MCF5282 CPUs
CONFIG_MONITOR_IS_IN_RAM
- -- defined if u-boot is loaded by a pre-loader
+ -- defined if U-Boot is loaded by a pre-loader
CONFIG_SYS_MBAR -- defines the base address of the MCF5282 internal register space
CONFIG_SYS_INIT_RAM_ADDR
diff --git a/doc/README.malta b/doc/README.malta
index c8db8a0..8614696 100644
--- a/doc/README.malta
+++ b/doc/README.malta
@@ -13,4 +13,4 @@
reset
flash-boot /path/to/u-boot/u-boot.bin
- - You should now be able to reboot your Malta to a U-boot shell.
+ - You should now be able to reboot your Malta to a U-Boot shell.
diff --git a/doc/README.menu b/doc/README.menu
index ad520ab..cf14231 100644
--- a/doc/README.menu
+++ b/doc/README.menu
@@ -4,7 +4,7 @@
* SPDX-License-Identifier: GPL-2.0+
*/
-U-boot provides a set of interfaces for creating and using simple, text
+U-Boot provides a set of interfaces for creating and using simple, text
based menus. Menus are displayed as lists of labeled entries on the
console, and an entry can be selected by entering its label.
diff --git a/doc/README.mpc83xxads b/doc/README.mpc83xxads
index d456103..7a8b706 100644
--- a/doc/README.mpc83xxads
+++ b/doc/README.mpc83xxads
@@ -80,7 +80,7 @@
tftp 10000 u-boot.bin
-5.1 Reflash U-boot Image using U-boot
+5.1 Reflash U-Boot Image using U-Boot
tftp 10000 u-boot.bin
protect off fe000000 fe09ffff
diff --git a/doc/README.mpc85xx-spin-table b/doc/README.mpc85xx-spin-table
index 8da768a..72c7bd7 100644
--- a/doc/README.mpc85xx-spin-table
+++ b/doc/README.mpc85xx-spin-table
@@ -1,7 +1,7 @@
Spin table in cache
=====================================
As specified by ePAPR v1.1, the spin table needs to be in cached memory. After
-DDR is initialized and U-boot relocates itself into DDR, the spin table is
+DDR is initialized and U-Boot relocates itself into DDR, the spin table is
accessible for core 0. It is part of release.S, within 4KB range after
__secondary_start_page. For other cores to use the spin table, the booting
process is described below:
diff --git a/doc/README.mpc85xxads b/doc/README.mpc85xxads
index 28bbcbe..ef92739 100644
--- a/doc/README.mpc85xxads
+++ b/doc/README.mpc85xxads
@@ -107,7 +107,7 @@
2. MEMORY MAP TO WORK WITH LINUX KERNEL
2.1. For the initial bringup, we adopted a consistent memory scheme
- between u-boot and linux kernel, you can customize it based on your
+ between U-Boot and linux kernel, you can customize it based on your
system requirements:
0x0000_0000 0x7fff_ffff DDR 2G
@@ -192,7 +192,7 @@
and future revisions of 8540/8560.
-4.4 Reflash U-boot Image using U-boot
+4.4 Reflash U-Boot Image using U-Boot
tftp 10000 u-boot.bin
protect off fff80000 ffffffff
diff --git a/doc/README.mpc85xxcds b/doc/README.mpc85xxcds
index bc5db0c..79d71cb 100644
--- a/doc/README.mpc85xxcds
+++ b/doc/README.mpc85xxcds
@@ -25,7 +25,7 @@
Memory Map
----------
-The memory map for u-boot and linux has been extended w.r.t. the ADS
+The memory map for U-Boot and linux has been extended w.r.t. the ADS
platform to allow for utilization of all 85xx CDS devices. The memory
map is setup for linux to operate properly. The linux source when
configured for MPC85xx CDS has been updated to reflect the new memory
@@ -55,14 +55,14 @@
There is a switch which allows the boot-bank to be selected. The switch
settings for updating flash are given below.
-The u-boot commands for copying the boot-bank into the secondary bank are
+The U-Boot commands for copying the boot-bank into the secondary bank are
as follows:
erase ff780000 ff7fffff
cp.b fff80000 ff780000 80000
-U-boot/kermit commands for downloading an image, then copying
+U-Boot/kermit commands for downloading an image, then copying
it into the secondary bank:
loadb
@@ -76,7 +76,7 @@
cp.b $loadaddr ff780000 80000
-U-boot commands for downloading an image via tftp and flashing
+U-Boot commands for downloading an image via tftp and flashing
it into the second bank:
tftp 10000 <u-boot.bin.image>
@@ -211,7 +211,7 @@
Flash Bank 2 @ 0xff000000
Ram @ 0
-Commands for downloading a u-boot image to memory from edink:
+Commands for downloading a U-Boot image to memory from edink:
env -c
time -s 4/8/2004 4:30p
diff --git a/doc/README.mxs b/doc/README.mxs
index ed2e568..6ea73b9 100644
--- a/doc/README.mxs
+++ b/doc/README.mxs
@@ -1,4 +1,4 @@
-Booting U-boot on a MXS processor
+Booting U-Boot on a MXS processor
=================================
This document describes the MXS U-Boot port. This document mostly covers topics
@@ -23,7 +23,7 @@
2) Compiling U-Boot for a MXS based board
3) Installation of U-Boot for a MXS based board to SD card
4) Installation of U-Boot into NAND flash on a MX28 based board
-5) Installation of U-boot into SPI NOR flash on a MX28 based board
+5) Installation of U-Boot into SPI NOR flash on a MX28 based board
1) Prerequisites
----------------
@@ -95,19 +95,19 @@
Examples:
-1. For building U-boot for Denx M28EVK board:
+1. For building U-Boot for Denx M28EVK board:
$ make m28evk_config
-2. For building U-boot for Freescale MX28EVK board:
+2. For building U-Boot for Freescale MX28EVK board:
$ make mx28evk_config
-3. For building U-boot for Freescale MX23EVK board:
+3. For building U-Boot for Freescale MX23EVK board:
$ make mx23evk_config
-4. For building U-boot for Olimex MX23 Olinuxino board:
+4. For building U-Boot for Olimex MX23 Olinuxino board:
$ make mx23_olinuxino_config
@@ -267,7 +267,7 @@
5) Installation of U-Boot into SPI NOR flash on a MX28 based board
------------------------------------------------------------------
-The u-boot.sb file can be directly written to SPI NOR from U-boot prompt.
+The u-boot.sb file can be directly written to SPI NOR from U-Boot prompt.
Load u-boot.sb into RAM, this can be done in several ways and one way is to use
tftp:
@@ -278,7 +278,7 @@
(SPI NOR should be succesfully detected in this step)
-Erase the blocks where U-boot binary will be written to:
+Erase the blocks where U-Boot binary will be written to:
=> sf erase 0x0 0x80000
Write u-boot.sb to SPI NOR:
@@ -287,4 +287,4 @@
Power off the board and set the boot mode DIP switches to boot from the SPI NOR
according to MX28 manual section 12.2.1 (Table 12-2)
-Last step is to power up the board and U-boot should start from SPI NOR.
+Last step is to power up the board and U-Boot should start from SPI NOR.
diff --git a/doc/README.odroid b/doc/README.odroid
index 8a004ca..ef243d1 100644
--- a/doc/README.odroid
+++ b/doc/README.odroid
@@ -1,4 +1,4 @@
- U-boot for Odroid X2/U3/XU3
+ U-Boot for Odroid X2/U3/XU3
========================
1. Summary
@@ -36,7 +36,7 @@
4. Boot media layout
====================
-The table below shows SD/eMMC cards layout for U-boot.
+The table below shows SD/eMMC cards layout for U-Boot.
The block offset is starting from 0 and the block size is 512B.
-------------------------------------
| Binary | Block offset| part type |
@@ -44,7 +44,7 @@
-------------------------------------
| Bl1 | 1 | 0 | 1 (boot) |
| Bl2 | 31 | 30 | 1 (boot) |
-| U-boot | 63 | 62 | 1 (boot) |
+| U-Boot | 63 | 62 | 1 (boot) |
| Tzsw | 2111 | 2110 | 1 (boot) |
| Uboot Env | 2560 | 2560 | 0 (user) |
-------------------------------------
@@ -62,18 +62,18 @@
without problem)
This is all you need to boot this board. But if you want to use your custom
-u-boot then you need to change u-boot.bin with your own u-boot binary*
+U-Boot then you need to change u-boot.bin with your own U-Boot binary*
and run the script "sd_fusing.sh" - this script is valid only for SD card.
*note:
-The proper binary file of current U-boot is u-boot-dtb.bin.
+The proper binary file of current U-Boot is u-boot-dtb.bin.
quick steps for Linux:
- Download all files from the link at point 3 and extract it if needed.
- put any SD card into the SD reader
- check the device with "dmesg"
- run ./sd_fusing.sh /dev/sdX - where X is SD card device (but not a partition)
-Check if Hardkernel U-boot is booting, and next do the same with your U-boot.
+Check if Hardkernel U-Boot is booting, and next do the same with your U-Boot.
6. Prepare the eMMC boot card
with a eMMC card reader (boot from eMMC card slot)
@@ -92,19 +92,19 @@
If you have an eMMC->microSD adapter you can prepare the card as in point 5.
But then the device can boot only from the SD card slot.
-8. Prepare the boot media using Hardkernel U-boot
+8. Prepare the boot media using Hardkernel U-Boot
=================================================
-You can update the U-boot to the custom one if you have a working bootloader
+You can update the U-Boot to the custom one if you have a working bootloader
delivered with the board on the eMMC/SD card. Then follow the steps:
- install the android fastboot tool
- connect a micro usb cable to the board
-- on the U-boot prompt, run command: fastboot (as a root)
+- on the U-Boot prompt, run command: fastboot (as a root)
- on the host, run command: "fastboot flash bootloader u-boot-dtb.bin"
-- the custom U-boot should start after the board resets.
+- the custom U-Boot should start after the board resets.
9. Partition layout
====================
-Default U-boot environment is setup for fixed partition layout.
+Default U-Boot environment is setup for fixed partition layout.
Partition table: MSDOS. Disk layout and files as listed in the table below.
----- ------ ------ ------ -------- ---------------------------------
diff --git a/doc/README.pxe b/doc/README.pxe
index bd175eb..cc182c9 100644
--- a/doc/README.pxe
+++ b/doc/README.pxe
@@ -5,8 +5,8 @@
*/
The 'pxe' commands provide a near subset of the functionality provided by
-the PXELINUX boot loader. This allows U-boot based systems to be controlled
-remotely using the same PXE based techniques that many non U-boot based servers
+the PXELINUX boot loader. This allows U-Boot based systems to be controlled
+remotely using the same PXE based techniques that many non U-Boot based servers
use.
Commands
@@ -99,7 +99,7 @@
lines is ignored.
The size of pxe files and the number of labels is only limited by the amount
-of RAM available to U-boot. Memory for labels is dynamically allocated as
+of RAM available to U-Boot. Memory for labels is dynamically allocated as
they're parsed, and memory for pxe files is statically allocated, and its
location is given by the pxefile_addr_r environment variable. The pxe code is
not aware of the size of the pxefile memory and will outgrow it if pxe files
@@ -206,38 +206,38 @@
Differences with PXELINUX
=========================
-The biggest difference between U-boot's pxe and PXELINUX is that since
-U-boot's pxe support is written entirely in C, it can run on any platform
-with network support in U-boot. Here are some other differences between
-PXELINUX and U-boot's pxe support.
+The biggest difference between U-Boot's pxe and PXELINUX is that since
+U-Boot's pxe support is written entirely in C, it can run on any platform
+with network support in U-Boot. Here are some other differences between
+PXELINUX and U-Boot's pxe support.
-- U-boot's pxe does not support the PXELINUX DHCP option codes specified
+- U-Boot's pxe does not support the PXELINUX DHCP option codes specified
in RFC 5071, but could be extended to do so.
-- when U-boot's pxe fails to boot, it will return control to U-boot,
- allowing another command to run, other U-boot command, instead of resetting
+- when U-Boot's pxe fails to boot, it will return control to U-Boot,
+ allowing another command to run, other U-Boot command, instead of resetting
the machine like PXELINUX.
-- U-boot's pxe doesn't rely on or provide an UNDI/PXE stack in memory, it
- only uses U-boot.
+- U-Boot's pxe doesn't rely on or provide an UNDI/PXE stack in memory, it
+ only uses U-Boot.
-- U-boot's pxe doesn't provide the full menu implementation that PXELINUX
+- U-Boot's pxe doesn't provide the full menu implementation that PXELINUX
does, only a simple text based menu using the commands described in
this README. With PXELINUX, it's possible to have a graphical boot
- menu, submenus, passwords, etc. U-boot's pxe could be extended to support
+ menu, submenus, passwords, etc. U-Boot's pxe could be extended to support
a more robust menuing system like that of PXELINUX's.
-- U-boot's pxe expects U-boot uimg's as kernels. Anything that would work
- with the 'bootm' command in U-boot could work with the 'pxe boot' command.
+- U-Boot's pxe expects U-Boot uimg's as kernels. Anything that would work
+ with the 'bootm' command in U-Boot could work with the 'pxe boot' command.
-- U-boot's pxe only recognizes a single file on the initrd command line. It
+- U-Boot's pxe only recognizes a single file on the initrd command line. It
could be extended to support multiple.
-- in U-boot's pxe, the localboot command doesn't necessarily cause a local
+- in U-Boot's pxe, the localboot command doesn't necessarily cause a local
disk boot - it will do whatever is defined in the 'localcmd' env
variable. And since it doesn't support a full UNDI/PXE stack, the
type field is ignored.
-- the interactive prompt in U-boot's pxe only allows you to choose a label
+- the interactive prompt in U-Boot's pxe only allows you to choose a label
from the menu. If you want to boot something not listed, you can ctrl+c
- out of 'pxe boot' and use existing U-boot commands to accomplish it.
+ out of 'pxe boot' and use existing U-Boot commands to accomplish it.
diff --git a/doc/README.qemu-mips b/doc/README.qemu-mips
index a192752..3940fac 100644
--- a/doc/README.qemu-mips
+++ b/doc/README.qemu-mips
@@ -157,7 +157,7 @@
(gdb) target remote localhost:1234
Remote debugging using localhost:1234
_start () at start.S:64
-64 RVECENT(reset,0) /* U-boot entry point */
+64 RVECENT(reset,0) /* U-Boot entry point */
Current language: auto; currently asm
(gdb) b board.c:289
Breakpoint 1 at 0xbfc00cc8: file board.c, line 289.
diff --git a/doc/README.sata b/doc/README.sata
index d0ce667..b1104bb 100644
--- a/doc/README.sata
+++ b/doc/README.sata
@@ -1,4 +1,4 @@
-1. SATA usage in U-boot
+1. SATA usage in U-Boot
There are two ways to operate the hard disk
@@ -45,9 +45,9 @@
boot
=> bootm 200000 1000000 2000000
-1.3 How to load an image from an ext2 file system in U-boot?
+1.3 How to load an image from an ext2 file system in U-Boot?
- U-boot doesn't support writing to an ext2 file system, so the
+ U-Boot doesn't support writing to an ext2 file system, so the
files must be written by other means (e.g. linux).
=> ext2ls sata 0:1 /
diff --git a/doc/README.video b/doc/README.video
index 62ac17b..e7ae98a 100644
--- a/doc/README.video
+++ b/doc/README.video
@@ -32,13 +32,13 @@
Example: video-mode=fslfb:1280x1024-32@60,monitor=dvi
-U-boot sunxi video controller driver
+U-Boot sunxi video controller driver
====================================
-U-boot supports hdmi and lcd output on Allwinner sunxi SoCs, lcd output
+U-Boot supports hdmi and lcd output on Allwinner sunxi SoCs, lcd output
requires the CONFIG_VIDEO_LCD_MODE Kconfig value to be set.
-The sunxi u-boot driver supports the following video-mode options:
+The sunxi U-Boot driver supports the following video-mode options:
- monitor=[none|dvi|hdmi|lcd|vga|composite-*] - Select the video output to use
none: Disable video output.
diff --git a/doc/SPI/README.ti_qspi_flash b/doc/SPI/README.ti_qspi_flash
index 1b86d01..9064739 100644
--- a/doc/SPI/README.ti_qspi_flash
+++ b/doc/SPI/README.ti_qspi_flash
@@ -1,4 +1,4 @@
-QSPI U-boot support
+QSPI U-Boot support
------------------
Host processor is connected to serial flash device via qpsi
@@ -44,4 +44,4 @@
Testing
-------
A seperated file named README.dra_qspi_test has been created which gives all the
-details about the commands required to test qspi at u-boot level.
+details about the commands required to test qspi at U-Boot level.
diff --git a/doc/uImage.FIT/kernel.its b/doc/uImage.FIT/kernel.its
index 539cdbf..e668c3f 100644
--- a/doc/uImage.FIT/kernel.its
+++ b/doc/uImage.FIT/kernel.its
@@ -1,5 +1,5 @@
/*
- * Simple U-boot uImage source file containing a single kernel
+ * Simple U-Boot uImage source file containing a single kernel
*/
/dts-v1/;
diff --git a/doc/uImage.FIT/kernel_fdt.its b/doc/uImage.FIT/kernel_fdt.its
index 7e940d2..7c52148 100644
--- a/doc/uImage.FIT/kernel_fdt.its
+++ b/doc/uImage.FIT/kernel_fdt.its
@@ -1,5 +1,5 @@
/*
- * Simple U-boot uImage source file containing a single kernel and FDT blob
+ * Simple U-Boot uImage source file containing a single kernel and FDT blob
*/
/dts-v1/;
diff --git a/doc/uImage.FIT/multi.its b/doc/uImage.FIT/multi.its
index 881b749..37369ec 100644
--- a/doc/uImage.FIT/multi.its
+++ b/doc/uImage.FIT/multi.its
@@ -1,5 +1,5 @@
/*
- * U-boot uImage source file with multiple kernels, ramdisks and FDT blobs
+ * U-Boot uImage source file with multiple kernels, ramdisks and FDT blobs
*/
/dts-v1/;
diff --git a/doc/uImage.FIT/source_file_format.txt b/doc/uImage.FIT/source_file_format.txt
index 029f481..3175c9f 100644
--- a/doc/uImage.FIT/source_file_format.txt
+++ b/doc/uImage.FIT/source_file_format.txt
@@ -1,4 +1,4 @@
-U-boot new uImage source file format (bindings definition)
+U-Boot new uImage source file format (bindings definition)
==========================================================
Author: Marian Balakowicz <m8@semihalf.com>
@@ -14,7 +14,7 @@
replace direct passing of 'struct bd_info' which was used to boot pre-FDT
kernels.
-However, U-boot needs to support both techniques to provide backward
+However, U-Boot needs to support both techniques to provide backward
compatibility for platforms which are not FDT ready. Number of elements
playing role in the booting process has increased and now includes the FDT
blob. Kernel image, FDT blob and possibly ramdisk image - all must be placed
@@ -36,15 +36,15 @@
Libfdt has been selected for the new uImage format implementation as (1) it
provides needed functionality, (2) is actively maintained and developed and
-(3) increases code reuse as it is already part of the U-boot source tree.
+(3) increases code reuse as it is already part of the U-Boot source tree.
b) Terminology
This document defines new uImage structure by providing FDT bindings for new
-uImage internals. Bindings are defined from U-boot perspective, i.e. describe
-final form of the uImage at the moment when it reaches U-boot. User
+uImage internals. Bindings are defined from U-Boot perspective, i.e. describe
+final form of the uImage at the moment when it reaches U-Boot. User
perspective may be simpler, as some of the properties (like timestamps and
-hashes) will need to be filled in automatically by the U-boot mkimage tool.
+hashes) will need to be filled in automatically by the U-Boot mkimage tool.
To avoid confusion with the kernel FDT the following naming convention is
proposed for the new uImage format related terms:
@@ -61,7 +61,7 @@
The following picture shows how the new uImage is prepared. Input consists of
image source file (.its) and a set of data files. Image is created with the
-help of standard U-boot mkimage tool which in turn uses dtc (device tree
+help of standard U-Boot mkimage tool which in turn uses dtc (device tree
compiler) to produce image tree blob (.itb). Resulting .itb file is the
actual binary of a new uImage.