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

Use proper project name in README, rst and comment.
Done in connection to commit bb922ca3eb ("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
This commit is contained in:
Michal Simek 2023-09-08 09:11:31 +02:00
parent a77c2bd902
commit e6ff998cb0
7 changed files with 16 additions and 16 deletions

View file

@ -1,6 +1,6 @@
File: README.COBRA5272 File: README.COBRA5272
Author: Florian Schlote for Sentec elektronik (linux@sentec-elektronik.de) 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. COBRA5272 board.
Version: v01.00 Version: v01.00
Date: Tue Mar 30 00:28:33 CEST 2004 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 u-boot-x-x-x/board/cobra5272/README and
to the comments in u-boot-x-x-x/include/configs/cobra5272.h 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 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 1. as a standalone bootloader residing in flash & relocating itself to RAM on
startup automatically => "FLASH version" 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 prestage bootloader ("chainloading") & is running only from the RAM address it
is linked to => "RAM version" 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 since it can be used to make available s. th. like a "bootstrap
mechanism". mechanism".
@ -71,7 +71,7 @@ How to build the different images:
Flash version Flash version
------------------------------ ------------------------------
Compile u-boot Compile U-Boot
in dir ./u-boot-x-x-x/ 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 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 in configs/cobra5272_defconfig CONFIG_TEXT_BASE should be
CONFIG_TEXT_BASE=0xffe00000 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: then:
@ -116,7 +116,7 @@ please modify the settings:
CONFIG_MONITOR_IS_IN_RAM=y 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 in configs/cobra5272_defconfig CONFIG_TEXT_BASE should be

View file

@ -320,7 +320,7 @@ ulong get_bus_freq(ulong dummy)
int cpu_numcores(void) 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 * spinning and device tree nodes get driven by QEMU itself
*/ */
return 1; return 1;

View file

@ -83,7 +83,7 @@ Mainline status
--------------- ---------------
- Added basic board configurations support. - 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 boards named - zc70x, zed, microzed, zc770_xm010/xm011/xm012/xm013
- Added zynq drivers: - Added zynq drivers:

View file

@ -26,7 +26,7 @@ configure and build armv7 toolchain::
Notes Notes
^^^^^ ^^^^^
Output fragment is u-boot. Output fragment is U-Boot.
Loading Loading
------- -------
@ -38,7 +38,7 @@ Bootgen
^^^^^^^ ^^^^^^^
The first way is to use Xilinx FSBL (First stage 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:: image generation via Xilinx bootgen utility::

View file

@ -213,7 +213,7 @@ Disk identifier: 0xb712a870
Device Boot Start End Blocks Id System Device Boot Start End Blocks Id System
/dev/mmcblk0p1 3 16 112455 83 Linux /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. there.
8. Write the partition table and exit. 8. Write the partition table and exit.

View file

@ -216,7 +216,7 @@ fdt_high
0xffffffffffffffff (64-bit machines) then 0xffffffffffffffff (64-bit machines) then
the fdt will not be copied at all on boot. For this the fdt will not be copied at all on boot. For this
to work it must reside in writable memory, have 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 add the information it needs into it, and the memory
must be accessible by the kernel. This usage is strongly discouraged must be accessible by the kernel. This usage is strongly discouraged
however as it also stops U-Boot from ensuring the device tree starting however as it also stops U-Boot from ensuring the device tree starting

View file

@ -23,7 +23,7 @@ eMMC or other NV media are available.
There are two main ARM virtual Fixed Virtual Platform (FVP) models, There are two main ARM virtual Fixed Virtual Platform (FVP) models,
`Versatile Express (VE) FVP and BASE FVP `Versatile Express (VE) FVP and BASE FVP
<http://www.arm.com/products/tools/models/fast-models/foundation-model.php>`_. <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, platform using the license-free Foundation_v8 simulator. Fortunately,
the Foundation_v8 simulator also supports the BASE_FVP model which the Foundation_v8 simulator also supports the BASE_FVP model which
companies can purchase licenses for and contain much more functionality. companies can purchase licenses for and contain much more functionality.