u-boot README文件 中英文对照完整版
# SPDX-License-Identifier: GPL-2.0+
#
# (C) Copyright 2000 - 2013
# Wolfgang Denk, DENX Software Engineering, wd@denx.de.
Summary:
概述：
========
This directory contains the source code for U-Boot, a boot loader for
Embedded boards based on PowerPC, ARM, MIPS and several other
processors, which can be installed in a boot ROM and used to
initialize and test the hardware or to download and run application
code.
The development of U-Boot is closely related to Linux: some parts of
the source code originate in the Linux source tree, we have some
header files in common, and special provision has been made to
support booting of Linux images.
Some attention has been paid to make this software easily
configurable and extendable. For instance, all monitor commands are
implemented with the same call interface, so that it's very easy to
add new commands. Also, instead of permanently adding rarely used
code (for instance hardware test utilities) to the monitor, you can
load and run it dynamically.
此目录包含用于基于PowerPC、ARM、MIPS和其他处理器的嵌入式板卡的U-Boot的源代码，可以将其安装到引导ROM中，用于初始化、测试硬件或下载并运行应用程序代码。
U-Boot的开发与Linux密切相关：部分源代码源自Linux源树，我们有一些共同的头文件，并且已经做出特殊规定以支持Linux映像的引导。
已经注意简化此软件以使其易于配置和扩展。例如，所有监视器命令都使用相同的调用接口进行实现，因此添加新命令非常容易。
此外，并非永久添加很少使用的代码（例如硬件测试实用程序）到监视器中，可以动态加载并运行它。
```
Status:
=======
In general, all boards for which a configuration option exists in the
Makefile have been tested to some extent and can be considered
"working". In fact, many of them are used in production systems.
In case of problems see the CHANGELOG file to find out who contributed
the specific port. In addition, there are various MAINTAINERS files
scattered throughout the U-Boot source identifying the people or
companies responsible for various boards and subsystems.
Note: As of August, 2010, there is no longer a CHANGELOG file in the
actual U-Boot source tree; however, it can be created dynamically
from the Git log using:
make CHANGELOG
状态：
一般来说，Makefile中有配置选项的板子都经过了一定程度的测试，可以被认为“工作正常”。事实上，其中许多板子都用于生产系统。
如果出现任何问题，请查看CHANGELOG文件以找出谁贡献了特定的端口。此外，在U-Boot源代码中分散着各种MAINTAINERS文件，用于识别负责各种开发板和子系统的个人或公司。
注意：截至2010年8月，实际的U-Boot源代码树中不再有CHANGELOG文件；但是，可以使用以下命令从Git日志动态创建：
make CHANGELOG
Where to get help:
==================
In case you have questions about, problems with or contributions for
U-Boot, you should send a message to the U-Boot mailing list at
<u-boot@lists.denx.de>. There is also an archive of previous traffic
on the mailing list - please search the archive before asking FAQ's.
Please see https://lists.denx.de/pipermail/u-boot and
https://marc.info/?l=u-boot
在哪里获得帮助：
如果您对以下内容有疑问、问题或贡献
U-Boot，您应该向U-Boot邮件列表发送消息，地址为
mailto:u-boot@lists.denx.de。还有一个以前流量的存档
在邮件列表上 - 在询问常见问题之前，请搜索存档。
请参阅 https://lists.denx.de/pipermail/u-boot和
https://marc.info/?l=u-boot
Where to get source code:
如何获取源代码：
=========================
The U-Boot source code is maintained in the Git repository at
https://source.denx.de/u-boot/u-boot.git ; you can browse it online at
https://source.denx.de/u-boot/u-boot
The "Tags" links on this page allow you to download tarballs of
any version you might be interested in. Official releases are also
available from the DENX file server through HTTPS or FTP.
https://ftp.denx.de/pub/u-boot/
ftp://ftp.denx.de/pub/u-boot/
U-Boot源代码由位于https://source.denx.de/u-boot/u-boot.git的Git仓库维护；您可以在线浏览它，网址为https://source.denx.de/u-boot/u-boot。
此页面上的“Tags”链接允许您下载任何您可能感兴趣的版本的tarball。官方版本也可通过HTTPS或FTP从DENX文件服务器上获得。
https://ftp.denx.de/pub/u-boot/
ftp://ftp.denx.de/pub/u-boot/
Where we come from:
从哪里开始
===================
- start from 8xxrom sources
- create PPCBoot project (https://sourceforge.net/projects/ppcboot)
- clean up code
- make it easier to add custom boards
- make it possible to add other [PowerPC] CPUs
- extend functions, especially:
* Provide extended interface to Linux boot loader
* S-Record download
* network boot
* ATA disk / SCSI ... boot
- create ARMBoot project (https://sourceforge.net/projects/armboot)
- add other CPU families (starting with ARM)
- create U-Boot project (https://sourceforge.net/projects/u-boot)
- current project page: see https://www.denx.de/wiki/U-Boot
从8xxrom源码开始
创建PPCBoot项目（https://sourceforge.net/projects/ppcboot）
清理代码
更容易添加自定义板
使其可以添加其他[PowerPC] CPU
扩展功能，特别是：
提供 Linux 引导加载程序的扩展接口
S-Record下载
网络引导
ATA 磁盘/SCSI...靴子
创建ARMBoot项目（https://sourceforge.net/projects/armboot）
添加其他CPU系列（从ARM开始）
创建U-Boot项目（https://sourceforge.net/projects/u-boot）
当前项目页面：请参阅https://www.denx.de/wiki/U-Boot
Names and Spelling:
项目名称及拼写：
===================
The "official" name of this project is "Das U-Boot". The spelling
"U-Boot" shall be used in all written text (documentation, comments
in source files etc.). Example:
This is the README file for the U-Boot project.
File names etc. shall be based on the string "u-boot". Examples:
include/asm-ppc/u-boot.h
#include <asm/u-boot.h>
Variable names, preprocessor constants etc. shall be either based on
the string "u_boot" or on "U_BOOT". Example:
U_BOOT_VERSION u_boot_logo
IH_OS_U_BOOT u_boot_hush_start
本项目的“官方”名称是“Das U-Boot”。在所有书面文本（文档、源文件注释等）中，应使用“U-Boot”的拼写。例如：
“这是U-Boot项目的Readme文件。”
文件名等应以“u-boot”字符串为基础。例如：
`include/asm-ppc/u-boot.h`
`#include <asm/u-boot.h>`
变量名、预处理器常量等应基于“u_boot”或“U_BOOT”。例如：
`U_BOOT_VERSION` `u_boot_logo`
`IH_OS_U_BOOT` `u_boot_hush_start`
Versioning:
版本控制：
===========
Starting with the release in October 2008, the names of the releases
were changed from numerical release numbers without deeper meaning
into a time stamp based numbering. Regular releases are identified by
names consisting of the calendar year and month of the release date.
Additional fields (if present) indicate release candidates or bug fix
releases in "stable" maintenance trees.
Examples:
U-Boot v2009.11 - Release November 2009
U-Boot v2009.11.1 - Release 1 in version November 2009 stable tree
U-Boot v2010.09-rc1 - Release candidate 1 for September 2010 release
从2008年10月的版本开始，发布版本的名称从没有深层含义的数字版本号改为了基于时间戳的编号。
常规版本以发布日期的年份和月份命名。附加字段（如果有）表示“稳定”维护树中的发布候选版本或bug修复版本。
示例：
U-Boot v2009.11 - 2009 年 11 月发布
U-Boot v2009.11.1 - 2009 年 11 月版本 1 稳定树
U-Boot v2010.09-rc1 - 2010 年 9 月的候选版本 1
Directory Hierarchy:
目录层次结构：
====================
/arch Architecture-specific files
/arc Files generic to ARC architecture
/arm Files generic to ARM architecture
/m68k Files generic to m68k architecture
/microblaze Files generic to microblaze architecture
/mips Files generic to MIPS architecture
/nios2 Files generic to Altera NIOS2 architecture
/powerpc Files generic to PowerPC architecture
/riscv Files generic to RISC-V architecture
/sandbox Files generic to HW-independent "sandbox"
/sh Files generic to SH architecture
/x86 Files generic to x86 architecture
/xtensa Files generic to Xtensa architecture
/api Machine/arch-independent API for external apps
/board Board-dependent files
/boot Support for images and booting
/cmd U-Boot commands functions
/common Misc architecture-independent functions
/configs Board default configuration files
/disk Code for disk drive partition handling
/doc Documentation (a mix of ReST and READMEs)
/drivers Device drivers
/dts Makefile for building internal U-Boot fdt.
/env Environment support
/examples Example code for standalone applications, etc.
/fs Filesystem code (cramfs, ext2, jffs2, etc.)
/include Header Files
/lib Library routines generic to all architectures
/Licenses Various license files
/net Networking code
/post Power On Self Test
/scripts Various build scripts and Makefiles
/test Various unit test files
/tools Tools to build and sign FIT images, etc.
/arch 架构特定的文件
/arc ARC体系结构通用文件
/arm ARM体系结构通用文件
/m68k m68k体系结构通用文件
/microblaze MicroBlaze体系结构通用文件
/mips MIPS体系结构通用文件
/nios2 Altera NIOS2体系结构通用文件
/powerpc PowerPC体系结构通用文件
/riscv RISC-V体系结构通用文件
/sandbox 硬件独立“沙箱”通用文件
/sh SH体系结构通用文件
/x86 x86体系结构通用文件
/xtensa Xtensa体系结构通用文件
/api 机器/体系结构独立API，供外部应用程序使用
/board 板卡相关的文件
/boot 镜像与启动支持
/cmd U-Boot命令函数
/common 体系结构无关的杂项函数
/configs 板卡默认配置文件
/disk 磁盘驱动分区处理代码
/doc 文档（包括ReST和README等）
/drivers 设备驱动程序
/dts Makefile用于构建内部U-Boot fdt。
/env 环境支持
/examples 示例代码，用于独立应用程序等。
/fs 文件系统代码（cramfs、ext2、jffs2等）
/include 头文件
/lib 库函数，通用所有体系结构
/Licenses 各种许可文件
/net 网络代码
/post 上电自测(Power On Self Test)
/scripts 各种构建脚本和Makefile
/test 各种单元测试文件
/tools 用于构建和签名FIT镜像等的工具
Software Configuration:
软件配置：
=======================
Selection of Processor Architecture and Board Type:
处理器体系结构和板卡类型的选择：
---------------------------------------------------
For all supported boards there are ready-to-use default
configurations available; just type "make <board_name>_defconfig".
对于所有支持的板卡，都有现成的默认配置可用；只需键入“make <board_name>_defconfig”。
Example: For a TQM823L module type:
例如：对于TQM823L模块类型：
cd u-boot
make TQM823L_defconfig
Note: If you're looking for the default configuration file for a board
you're sure used to be there but is now missing, check the file
doc/README.scrapyard for a list of no longer supported boards.
注意：如果您正在寻找一个以前存在但现在缺失的特定板卡的默认配置文件，请检查文件doc/README.scrapyard以获取不再支持的板卡列表。
Sandbox Environment:
沙箱环境：
--------------------
U-Boot can be built natively to run on a Linux host using the 'sandbox'
board. This allows feature development which is not board- or architecture-
specific to be undertaken on a native platform. The sandbox is also used to
run some of U-Boot's tests.
See doc/arch/sandbox.rst for more details.
U-Boot可以在Linux主机上本地构建并运行，使用'sandbox'板。这使得非特定板卡或体系结构的功能开发可以在本机平台上进行。沙箱还用于运行U-Boot的一些测试。
更多详情，请参阅doc/arch/sandbox.rst。
Board Initialisation Flow:
板初始化流程：
--------------------------
This is the intended start-up flow for boards. This should apply for both
SPL and U-Boot proper (i.e. they both follow the same rules).
这是板的预启动流程。这应该适用于SPL和U-Boot proper（即它们遵循相同的规则）。
Note: "SPL" stands for "Secondary Program Loader," which is explained in
more detail later in this file.
注：“SPL”代表“Secondary Program Loader”，稍后在本文件中会有更详细的解释。
At present, SPL mostly uses a separate code path, but the function names
and roles of each function are the same. Some boards or architectures
may not conform to this. At least most ARM boards which use
CONFIG_SPL_FRAMEWORK conform to this.
目前，SPL主要使用独立的代码路径，但每个函数的功能名称和角色相同。某些板或体系结构可能不符合此要求。
至少大多数使用CONFIG_SPL_FRAMEWORK的ARM板符合此要求。
Execution typically starts with an architecture-specific (and possibly
CPU-specific) start.S file, such as:
- arch/arm/cpu/armv7/start.S
- arch/powerpc/cpu/mpc83xx/start.S
- arch/mips/cpu/start.S
and so on. From there, three functions are called; the purpose and
limitations of each of these functions are described below.
执行通常从特定体系结构（可能也是特定CPU）的start.S文件开始，例如：
- arch/arm/cpu/armv7/start.S
- arch/powerpc/cpu/mpc83xx/start.S
- arch/mips/cpu/start.S
等等。从那里开始，会调用三个函数；每个函数的用途和限制如下。
lowlevel_init():
- purpose: essential init to permit execution to reach board_init_f()
- no global_data or BSS
- there is no stack (ARMv7 may have one but it will soon be removed)
- must not set up SDRAM or use console
- must only do the bare minimum to allow execution to continue to
board_init_f()
- this is almost never needed
- return normally from this function
低级初始化：
-目的：必需的 init，以允许执行到达 board_init_f()
-无 global_data 或 BSS
-没有栈（ARMv7 可能有一个，但很快就会被删除）
-不得设置 SDRAM 或使用控制台
-必须只做最低限度的努力，以允许执行继续进行
-板初始化函数()
-这几乎从来不需要
-从该函数正常返回
board_init_f():
- purpose: set up the machine ready for running board_init_r():
i.e. SDRAM and serial UART
- global_data is available
- stack is in SRAM
- BSS is not available, so you cannot use global/static variables,
only stack variables and global_data
Non-SPL-specific notes:
- dram_init() is called to set up DRAM. If already done in SPL this
can do nothing
SPL-specific notes:
- you can override the entire board_init_f() function with your own
version as needed.
- preloader_console_init() can be called here in extremis
- should set up SDRAM, and anything needed to make the UART work
- there is no need to clear BSS, it will be done by crt0.S
- for specific scenarios on certain architectures an early BSS *can*
be made available (via CONFIG_SPL_EARLY_BSS by moving the clearing
of BSS prior to entering board_init_f()) but doing so is discouraged.
Instead it is strongly recommended to architect any code changes
or additions such to not depend on the availability of BSS during
board_init_f() as indicated in other sections of this README to
maintain compatibility and consistency across the entire code base.
- must return normally from this function (don't call board_init_r()
directly)
Here the BSS is cleared. For SPL, if CONFIG_SPL_STACK_R is defined, then at
this point the stack and global_data are relocated to below
CONFIG_SPL_STACK_R_ADDR. For non-SPL, U-Boot is relocated to run at the top of
memory.
board_init_f():
-目的：为运行 board_init_r() 做好机器的准备，即 SDRAM 和串行 UART
-可获得 global_data
-堆栈位于 SRAM 中
-不可用 BSS，因此只能使用堆栈变量和 global_data，而不能使用全局/静态变量
非 SPL 特定说明：
-dram_init() 被调用以设置 DRAM。如果已在 SPL 中完成，则无法执行任何操作
SPL 特定说明：
-根据需要，可以覆盖整个 board_init_f() 函数
-在极端情况下，可以在这里调用 preloader_console_init()
-应设置 SDRAM，以及使 UART 正常工作所需的所有内容
-不需要清除 BSS，crt0.S 将完成此操作
-对于某些体系结构上的特定场景，可以提供早期 BSS（通过将清除 BSS 移至进入 board_init_f() 之前，通过 CONFIG_SPL_EARLY_BSS 进行配置）。
但不建议这样做。相反，强烈建议对任何代码更改或添加进行架构设计，以便在 board_init_f() 期间不依赖 BSS 的可用性，如本 README 的其他部分所示，
以在整个代码库中维护兼容性和一致性。
-此函数必须正常返回（不能直接调用 board_init_r()）
在U-Boot中，BSS段（bss segment）通常是指用来存放程序中未初始化的全局变量的一块内存区域。BSS是英文Block Started by Symbol的简称。BSS段属于静态内存分配。
在这里清除了BSS。对于SPL，如果定义了CONFIG_SPL_STACK_R，那么此时堆栈和global_data将被重新定位到低于CONFIG_SPL_STACK_R_ADDR的位置。对于非SPL，U-Boot被重新定位到运行在内存的顶部。
board_init_r():
- purpose: main execution, common code
- global_data is available
- SDRAM is available
- BSS is available, all static/global variables can be used
- execution eventually continues to main_loop()
-用途：main 执行，通用代码
-global_data可用
-SDRAM可用
-BSS可用，所有静态/全局变量都可以使用
-执行最终会继续到 main_loop()
非SPL特定注意事项：
Non-SPL-specific notes:
- U-Boot is relocated to the top of memory and is now running from
there.
U-Boot 被重新定位到内存顶部，然后从那里开始执行
SPL 特定注意事项：
SPL-specific notes:
- stack is optionally in SDRAM, if CONFIG_SPL_STACK_R is defined and
CONFIG_SYS_FSL_HAS_CCI400
Defined For SoC that has cache coherent interconnect
CCN-400
CONFIG_SYS_FSL_HAS_CCN504
Defined for SoC that has cache coherent interconnect CCN-504
-如果定义了CONFIG_SPL_stack_R
CONFIG_SYS_FSL_HAS_CCI400 采用缓存一致性 CCN-400
CONFIG_SYS_FSL_HAS_CCN504 采用混穿一致性 CCN-504
CCN-400和CCN-504是Freescale（飞思卡尔）公司定义的两种不同的缓存一致性网络（Cache Coherent Network）类型。这些网络主要用于在多处理器系统中实现各处理器之间缓存的一致性，即保证当一个处理器修改了某块内存区域的数据后，其他处理器访问该内存区域时能够获取到最新的数据。
CCN-400：这是Freescale的第一代缓存一致性网络，它基于目录协议（Directory Protocol）。这种协议中，每个缓存行都有一个目录条目，用来记录当前缓存行在哪些其他缓存中有所有的拷贝。当一个处理器需要访问某一块内存区域时，它首先查看对应的目录条目，来确定这块内存区域在其他处理器的缓存中的状态。
CCN-504：这是Freescale的第二代缓存一致性网络，它基于流控制协议（Flow Control Protocol）。这种协议中，每个缓存行都有一个流控制块，用来记录当前缓存行在其他处理器的缓存中的状态以及对应的流控制块。当一个处理器需要访问某一块内存区域时，它首先查看对应的流控制块，来确定这块内存区域在其他处理器的缓存中的状态，然后根据状态信息来控制数据的流动。
以上信息仅供参考，建议咨询专业的技术人员以获得权威解答。
The following options need to be configured:
- CPU Type: Define exactly one, e.g. CONFIG_MPC85XX.
- Board Type: Define exactly one, e.g. CONFIG_MPC8540ADS.
- 85xx CPU Options:
CONFIG_SYS_PPC64
Specifies that the core is a 64-bit PowerPC implementation (implements
the "64" category of the Power ISA). This is necessary for ePAPR
compliance, among other possible reasons.
CONFIG_SYS_FSL_ERRATUM_A004510
Enables a workaround for erratum A004510. If set,
then CONFIG_SYS_FSL_ERRATUM_A004510_SVR_REV and
CONFIG_SYS_FSL_CORENET_SNOOPVEC_COREONLY must be set.
CONFIG_SYS_FSL_ERRATUM_A004510_SVR_REV
CONFIG_SYS_FSL_ERRATUM_A004510_SVR_REV2 (optional)
Defines one or two SoC revisions (low 8 bits of SVR)
for which the A004510 workaround should be applied.
The rest of SVR is either not relevant to the decision
of whether the erratum is present (e.g. p2040 versus
p2041) or is implied by the build target, which controls
whether CONFIG_SYS_FSL_ERRATUM_A004510 is set.
See Freescale App Note 4493 for more information about
this erratum.
CONFIG_SYS_FSL_CORENET_SNOOPVEC_COREONLY
This is the value to write into CCSR offset 0x18600
according to the A004510 workaround.
CONFIG_SYS_FSL_SINGLE_SOURCE_CLK
Single Source Clock is clocking mode present in some of FSL SoC's.
In this mode, a single differential clock is used to supply
clocks to the sysclock, ddrclock and usbclock.
以下选项需要配置：
CPU类型：精确定义一个，例如 CONFIG_MPC85XX。
主板类型：精确定义一个，例如 CONFIG_MPC8540ADS。
85xx CPU选项：
CONFIG_SYS_PPC64
指定核心是64位PowerPC的实现（实现“64”Power ISA类别）。这对于ePAPR合规性以及其他可能的原因是必要的。
CONFIG_SYS_FSL_ERRATUM_A004510
启用针对erratum A004510的修复程序。如果设置了该选项，则必须设置 CONFIG_SYS_FSL_ERRATUM_A004510_SVR_REV 和 CONFIG_SYS_FSL_CORENET_SNOOPVEC_COREONLY。
CONFIG_SYS_FSL_ERRATUM_A004510_SVR_REV
CONFIG_SYS_FSL_ERRATUM_A004510_SVR_REV2（可选）
定义一个或两个SoC版本（SVR的低8位），对于这些版本应该应用A004510修复程序。
SVR的其余部分要么与决定是否存在erratum无关（例如 p2040 与 p2041），要么由构建目标隐含，它控制是否设置 CONFIG_SYS_FSL_ERRATUM_A004510。
请参阅Freescale App Note 4493以获取有关此erratum的更多信息。
CONFIG_SYS_FSL_CORENET_SNOOPVEC_COREONLY
根据A004510修复程序，这是要写入CCSR偏移0x18600的值。
CONFIG_SYS_FSL_SINGLE_SOURCE_CLK
单源时钟是FSL SoC中的一种时钟模式。在此模式下，使用单个差分时钟为sysclock、ddrclock和usbclock提供时钟。
- Generic CPU options:
CONFIG_SYS_FSL_DDR
Freescale DDR driver in use. This type of DDR controller is
found in mpc83xx, mpc85xx as well as some ARM core SoCs.
CONFIG_SYS_FSL_DDR_ADDR
Freescale DDR memory-mapped register base.
CONFIG_SYS_FSL_IFC_CLK_DIV
Defines divider of platform clock(clock input to IFC controller).
CONFIG_SYS_FSL_LBC_CLK_DIV
Defines divider of platform clock(clock input to eLBC controller).
CONFIG_SYS_FSL_DDR_SDRAM_BASE_PHY
Physical address from the view of DDR controllers. It is the
same as CONFIG_SYS_DDR_SDRAM_BASE for all Power SoCs. But
it could be different for ARM SoCs.
CONFIG_SYS_FSL_DDR: 这是一个标志，表示正在使用Freescale的DDR驱动这种DDR控制器在mpc83xx、mpc85xx以及一些ARM核心SoC中可以找到
CONFIG_SYS_FSL_DDR_ADDR: 这是Freescale DDR内存映射寄存器的基地址
CONFIG_SYS_FSL_IFC_CLK_DIV: 定义了平台时钟（输入到IFC控制器的时钟）的除法器
CONFIG_SYS_FSL_LBC_CLK_DIV: 定义了平台时钟（输入到eLBC控制器的时钟）的除法器
CONFIG_SYS_FSL_DDR_SDRAM_BASE_PHY: 从DDR控制器的视角来看，这是物理地址它对于所有Power SoC来说与CONFIG_SYS_DDR_SDRAM_BASE相同，但对于ARM SoC来说可能不同
- MIPS CPU options:
CONFIG_XWAY_SWAP_BYTES
Enable compilation of tools/xway-swap-bytes needed for Lantiq
XWAY SoCs for booting from NOR flash. The U-Boot image needs to
be swapped if a flash programmer is used.
这是一个关于MIPS CPU选项的问题。选项CONFIG_XWAY_SWAP_BYTES是用于启用一个特定于Lantiq XWAY SoCs的工具的编译，该工具用于从NOR flash引导。当使用flash编程器时，U-Boot镜像需要进行交换。
- ARM options:
CONFIG_SYS_EXCEPTION_VECTORS_HIGH
Select high exception vectors of the ARM core, e.g., do not
clear the V bit of the c1 register of CP15.
COUNTER_FREQUENCY
Generic timer clock source frequency.
COUNTER_FREQUENCY_REAL
Generic timer clock source frequency if the real clock is
different from COUNTER_FREQUENCY, and can only be determined
at run time.
CONFIG_SYS_EXCEPTION_VECTORS_HIGH: 这个选项用于选择ARM核心的高异常向量。例如，它不会清除CP15寄存器的c1位的V位。选择这个选项可能会影响到异常处理的方式，你需要根据具体的硬件和应用需求来决定是否启用它。
COUNTER_FREQUENCY: 这个选项用于设置通用定时器的时钟源频率。在大多数情况下，这个频率应该与你的系统时钟源匹配。如果你不确定应该设置什么值，你可能需要查阅你的硬件文档或者联系硬件供应商获取具体信息。
COUNTER_FREQUENCY_REAL: 这个选项也是用于设置通用定时器的时钟源频率，但是它只有在真实时钟与COUNTER_FREQUENCY选项设置的时钟不同时才会被用到。这个频率通常在运行时才能确定。如果你在编译时就能确定这个值，你可以设置它；否则，你应该在运行时动态地获取这个值。
- Tegra SoC options:
CONFIG_TEGRA_SUPPORT_NON_SECURE
Support executing U-Boot in non-secure (NS) mode. Certain
impossible actions will be skipped if the CPU is in NS mode,
such as ARM architectural timer initialization.
CONFIG_TEGRA_SUPPORT_NON_SECURE
这个选项用于支持在非安全（non-secure）模式下执行U-Boot某些CPU在非安全模式下会跳过一些不可能的操作，例如ARM架构定时器的初始化
- Linux Kernel Interface:
CONFIG_MEMSIZE_IN_BYTES [relevant for MIPS only]
When transferring memsize parameter to Linux, some versions
expect it to be in bytes, others in MB.
Define CONFIG_MEMSIZE_IN_BYTES to make it in bytes.
CONFIG_OF_LIBFDT
New kernel versions are expecting firmware settings to be
passed using flattened device trees (based on open firmware
concepts).
CONFIG_OF_LIBFDT
* New libfdt-based support
* Adds the "fdt" command
* The bootm command automatically updates the fdt
OF_TBCLK - The timebase frequency.
boards with QUICC Engines require OF_QE to set UCC MAC
addresses
CONFIG_OF_IDE_FIXUP
U-Boot can detect if an IDE device is present or not.
If not, and this new config option is activated, U-Boot
removes the ATA node from the DTS before booting Linux,
so the Linux IDE driver does not probe the device and
crash. This is needed for buggy hardware (uc101) where
no pull down resistor is connected to the signal IDE5V_DD7.
CONFIG_MEMSIZE_IN_BYTES: 此选项仅对MIPS有效。当向Linux传输memsize参数时，某些版本期望它以字节为单位，而其他版本则以MB为单位。定义这个选项可以使memsize参数以字节为单位。
CONFIG_OF_LIBFDT: 新版本的Linux期望固件设置使用扁平化的设备树（基于开放固件概念）传递。这个选项添加了基于libfdt的新支持，并添加了“fdt”命令，而“bootm”命令会自动更新fdt。
OF_TBCLK: 这是时间基准频率。
CONFIG_OF_IDE_FIXUP: U-Boot可以检测IDE设备是否存在。如果不存在，并且启用了这个新的配置选项，U-Boot会在引导Linux之前从DTS中移除ATA节点，这样Linux IDE驱动程序就不会探测设备并崩溃。这对于有缺陷的硬件（uc101）是必需的，因为在该硬件上没有连接信号IDE5V_DD7的拉电阻。
- vxWorks boot parameters:
bootvx constructs a valid bootline using the following
environments variables: bootdev, bootfile, ipaddr, netmask,
serverip, gatewayip, hostname, othbootargs.
It loads the vxWorks image pointed bootfile.
Note: If a "bootargs" environment is defined, it will override
the defaults discussed just above.
这段文本是关于 VxWorks 操作系统的引导参数的说明。VxWorks 是一种实时操作系统，常用于嵌入式系统开发。以下是关于这段文本的详细解释：
VxWorks 在引导时会使用一系列的环境变量来构造一个有效的引导行。这些环境变量包括：
bootdev：指定引导设备，即系统从哪个设备加载操作系统。
bootfile：指定 VxWorks 映像文件的位置。
ipaddr：指定设备的 IP 地址。
netmask：指定子网掩码。
serverip：指定 TFTP 服务器的 IP 地址，用于从服务器下载引导文件。
gatewayip：指定网关的 IP 地址。
hostname：指定设备的主机名。
othbootargs：其他引导参数。
VxWorks 会根据这些参数构造一个引导行，然后从指定的 bootfile 中加载 VxWorks 映像。
注意：如果定义了名为 "bootargs" 的环境变量，它将覆盖上述的默认参数。这意味着你可以在 "bootargs" 环境变量中指定所有的引导参数，从而覆盖其他的默认设置。
- Cache Configuration for ARM:
CONFIG_SYS_PL310_BASE - Physical base address of PL310
controller register space
在ARM体系结构中，PL310通常指的是ARM的L2 Cache控制器，这是一个位于CPU内部的二级缓存。在ARM的体系结构中，二级缓存通常被用于加速对主内存的访问。
CONFIG_SYS_PL310_BASE 是一个预处理器宏，它定义了PL310控制器的寄存器空间在物理内存中的基地址。这个基地址在程序中可以通过一个宏或者一个常量来访问，以便于控制和操作PL310控制器。
- Serial Ports:
CONFIG_PL011_CLOCK
If you have Amba PrimeCell PL011 UARTs, set this variable to
the clock speed of the UARTs.
CONFIG_PL01x_PORTS
If you have Amba PrimeCell PL010 or PL011 UARTs on your board,
define this to a list of base addresses for each (supported)
port. See e.g. include/configs/versatile.h
CONFIG_SERIAL_HW_FLOW_CONTROL
Define this variable to enable hw flow control in serial driver.
Current user of this option is drivers/serial/nsl16550.c driver
CONFIG_PL011_CLOCK: 如果你的设备上有Amba PrimeCell PL011 UART（通用异步接收/发送器），那么你需要设置这个变量为UART的时钟速度。
CONFIG_PL01x_PORTS: 如果你的板上有Amba PrimeCell PL010或PL011 UART，你需要定义这个选项为每个（支持的）端口的基本地址列表。例如，你可以查看include/configs/versatile.h文件。
CONFIG_SERIAL_HW_FLOW_CONTROL: 定义这个变量以在串行驱动程序中启用硬件流控制。当前这个选项的使用者是drivers/serial/nsl16550.c驱动程序。
- Serial Download Echo Mode:
CONFIG_LOADS_ECHO
If defined to 1, all characters received during a
serial download (using the "loads" command) are
echoed back. This might be needed by some terminal
emulations (like "cu"), but may as well just take
time on others. This setting #define's the initial
value of the "loads_echo" environment variable.
如果CONFIG_LOADS_ECHO被定义为1，那么在串行下载过程中（使用"loads"命令）接收到的所有字符都会被回显。这对于一些终端模拟（如"cu"）可能是必要的，但对于其他情况可能只会浪费时间。这个设置选项初始化了"loads_echo"环境变量的值。
换句话说，如果你在开发或调试过程中发现终端不回显你输入的字符，你可能需要将CONFIG_LOADS_ECHO设置为1。
这些设置通常需要在编译系统时进行设置，以适应特定的硬件和应用程序需求。在具体的代码或配置文件中查找更多关于如何改变这些设置的详细信息。
- Removal of commands
If no commands are needed to boot, you can disable
CONFIG_CMDLINE to remove them. In this case, the command line
will not be available, and when U-Boot wants to execute the
boot command (on start-up) it will call board_run_command()
instead. This can reduce image size significantly for very
simple boot procedures.
在U-Boot中，命令行接口是用于与U-Boot进行交互的主要方式之一。用户可以通过在命令行中输入命令来执行各种操作，如加载文件、设置环境变量、启动操作系统等。
然而，对于一些简单的引导过程，可能不需要使用命令行接口。文本中提到的CONFIG_CMDLINE是一个配置选项，用于启用或禁用命令行接口。如果不需要使用命令行接口，可以将CONFIG_CMDLINE禁用，这样在启动时就不会加载命令行接口，而是调用board_run_command()函数来执行启动命令。
禁用命令行接口可以显著减少U-Boot镜像的大小，这对于一些资源受限的嵌入式系统来说可能是必要的。但需要注意的是，如果需要使用命令行接口进行调试或进行更复杂的操作，禁用命令行接口可能会带来不便。
要在U-Boot中禁用命令行接口，可以在配置文件中将CONFIG_CMDLINE设置为n（表示禁用），然后重新编译和烧录U-Boot镜像。具体操作方法可以参考U-Boot的官方文档或相关开发指南
- Regular expression support:
CONFIG_REGEX
If this variable is defined, U-Boot is linked against
the SLRE (Super Light Regular Expression) library,
which adds regex support to some commands, as for
example "env grep" and "setexpr".
CONFIG_REGEX是一个配置选项，用于启用或禁用正则表达式支持。如果将CONFIG_REGEX定义为1，则U-Boot将链接到SLRE（Super Light Regular Expression）库，该库为一些命令添加正则表达式支持。
启用正则表达式支持后，可以使用正则表达式来匹配和处理文本数据。例如，使用"env grep"命令可以根据正则表达式搜索和过滤环境变量，使用"setexpr"命令可以根据正则表达式进行条件判断和操作。
要在U-Boot中启用正则表达式支持，可以将CONFIG_REGEX设置为1，然后重新编译和烧录U-Boot镜像。具体操作方法可以参考U-Boot的官方文档或相关开发指南。
- Watchdog:
CONFIG_SYS_WATCHDOG_FREQ
Some platforms automatically call WATCHDOG_RESET()
from the timer interrupt handler every
CONFIG_SYS_WATCHDOG_FREQ interrupts. If not set by the
board configuration file, a default of CONFIG_SYS_HZ/2
(i.e. 500) is used. Setting CONFIG_SYS_WATCHDOG_FREQ
to 0 disables calling WATCHDOG_RESET() from the timer
interrupt.
CONFIG_SYS_WATCHDOG_FREQ定义了看门狗定时器的频率。有些平台会在每次定时器中断时自动调用WATCHDOG_RESET()函数，而频率由CONFIG_SYS_WATCHDOG_FREQ定义。如果没有在板级配置文件中设置，
默认值是CONFIG_SYS_HZ/2（即500）。如果将CONFIG_SYS_WATCHDOG_FREQ设置为0，将禁用从定时器中断调用WATCHDOG_RESET()。
- Real-Time Clock:
When CONFIG_CMD_DATE is selected, the type of the RTC
has to be selected, too. Define exactly one of the
following options:
CONFIG_RTC_PCF8563 - use Philips PCF8563 RTC
CONFIG_RTC_MC13XXX - use MC13783 or MC13892 RTC
CONFIG_RTC_MC146818 - use MC146818 RTC
CONFIG_RTC_DS1307 - use Maxim, Inc. DS1307 RTC
CONFIG_RTC_DS1337 - use Maxim, Inc. DS1337 RTC
CONFIG_RTC_DS1338 - use Maxim, Inc. DS1338 RTC
CONFIG_RTC_DS1339 - use Maxim, Inc. DS1339 RTC
CONFIG_RTC_DS164x - use Dallas DS164x RTC
CONFIG_RTC_ISL1208 - use Intersil ISL1208 RTC
CONFIG_RTC_MAX6900 - use Maxim, Inc. MAX6900 RTC
CONFIG_RTC_DS1337_NOOSC - Turn off the OSC output for DS1337
CONFIG_SYS_RV3029_TCR - enable trickle charger on
RV3029 RTC.
Note that if the RTC uses I2C, then the I2C interface
must also be configured. See I2C Support, below.
当选择CONFIG_CMD_DATE时，必须选择RTC的类型。你可以定义以下选项中的任何一个：
CONFIG_RTC_PCF8563 - 使用Philips PCF8563 RTC。
CONFIG_RTC_MC13XXX - 使用MC13783或MC13892 RTC。
CONFIG_RTC_MC146818 - 使用MC146818 RTC。
CONFIG_RTC_DS1307 - 使用Maxim, Inc. DS1307 RTC。
CONFIG_RTC_DS1337 - 使用Maxim, Inc. DS1337 RTC。
CONFIG_RTC_DS1338 - 使用Maxim, Inc. DS1338 RTC。
CONFIG_RTC_DS1339 - 使用Maxim, Inc. DS1339 RTC。
CONFIG_RTC_DS164x - 使用Dallas DS164x RTC。
CONFIG_RTC_ISL1208 - 使用Intersil ISL1208 RTC。
CONFIG_RTC_MAX6900 - 使用Maxim, Inc. MAX6900 RTC。
CONFIG_RTC_DS1337_NOOSC - 为DS1337关闭OSC输出。
CONFIG_SYS_RV3029_TCR - 在RV3029 RTC上启用微电流充电器。
注意，如果RTC使用I2C，则还必须配置I2C接口。参见下面的I2C支持部分。
以上所有的选项都是预处理器宏，当选择其中的一个时，相关的硬件驱动程序将被包含在编译的代码中。如果没有选择，那么这个驱动程序将不会被包含。
- GPIO Support:
CONFIG_PCA953X - use NXP's PCA953X series I2C GPIO
The CONFIG_SYS_I2C_PCA953X_WIDTH option specifies a list of
chip-ngpio pairs that tell the PCA953X driver the number of
pins supported by a particular chip.
Note that if the GPIO device uses I2C, then the I2C interface
must also be configured. See I2C Support, below.
CONFIG_PCA953X，这是用于NXP（恩智浦半导体）的PCA953X系列I2C GPIO。
CONFIG_SYS_I2C_PCA953X_WIDTH选项指定了一个芯片-ngpio对的列表，这个列表告诉PCA953X驱动程序某个特定芯片支持的引脚数量。
请注意，如果GPIO设备使用I2C，那么还必须配置I2C接口。有关I2C支持的信息，请参阅下面的内容。
- I/O tracing:
When CONFIG_IO_TRACE is selected, U-Boot intercepts all I/O
accesses and can checksum them or write a list of them out
to memory. See the 'iotrace' command for details. This is
useful for testing device drivers since it can confirm that
the driver behaves the same way before and after a code
change. Currently this is supported on sandbox and arm. To
add support for your architecture, add '#include <iotrace.h>'
to the bottom of arch/<arch>/include/asm/io.h and test.
Example output from the 'iotrace stats' command is below.
Note that if the trace buffer is exhausted, the checksum will
still continue to operate.
iotrace is enabled
Start: 10000000 (buffer start address)
Size: 00010000 (buffer size)
Offset: 00000120 (current buffer offset)
Output: 10000120 (start + offset)
Count: 00000018 (number of trace records)
CRC32: 9526fb66 (CRC32 of all trace records)
当选择CONFIG_IO_TRACE时，U-Boot会拦截所有的I/O访问，并可以校验和它们，或者将它们写入内存中的列表。详见iotrace命令的说明。
这个功能对于测试设备驱动很有用，因为它可以确认驱动在代码更改之前和之后的行为是否相同。目前，这个功能在sandbox和arm上得到支持。
要为您的体系结构添加支持，请将#include <iotrace.h>添加到arch/<arch>/include/asm/io.h文件的底部并进行测试。
iotrace stats命令的示例输出如下。请注意，如果跟踪缓冲区已用尽，校验和仍然会继续运行。
iotrace是启用的
Start: 缓冲区的起始地址
Size: 缓冲区的大小
Offset: 当前缓冲区的偏移量
Output: 起始地址+偏移量
Count: 跟踪记录的数量
CRC32: 所有跟踪记录的CRC32值
这段信息显示了U-Boot的I/O跟踪功能的当前状态和参数。通过使用iotrace stats命令，您可以获取有关I/O跟踪的详细信息，包括缓冲区的起始地址、大小、当前偏移量、已记录的跟踪记录数量以及所有跟踪记录的CRC32校验值。
- Timestamp Support:
When CONFIG_TIMESTAMP is selected, the timestamp
(date and time) of an image is printed by image
commands like bootm or iminfo. This option is
automatically enabled when you select CONFIG_CMD_DATE .
当选择CONFIG_TIMESTAMP时，镜像的时间戳（日期和时间）将由像bootm或iminfo这样的镜像命令打印出来。当您选择CONFIG_CMD_DATE时，这个选项会自动启用。
换句话说，如果你在配置环境中启用了CONFIG_TIMESTAMP，那么当你使用诸如bootm或iminfo这样的命令来查看或加载镜像时，它会显示该镜像的创建日期和时间。这对于跟踪和管理镜像文件非常有用。
- Partition Labels (disklabels) Supported:
Zero or more of the following:
CONFIG_MAC_PARTITION Apple's MacOS partition table.
CONFIG_ISO_PARTITION ISO partition table, used on CDROM etc.
CONFIG_EFI_PARTITION GPT partition table, common when EFI is the
bootloader. Note 2TB partition limit; see
disk/part_efi.c
CONFIG_SCSI) you must configure support for at
least one non-MTD partition type as well.
这段文本是关于磁盘分区标签的支持说明。
这里提到了一些分区标签：
CONFIG_MAC_PARTITION：这是Apple的MacOS分区表。
CONFIG_ISO_PARTITION：这是ISO分区表，用于CDROM等。
CONFIG_EFI_PARTITION：这是GPT分区表，当EFI作为引导程序时常见。注意2TB分区的限制，详见disk/part_efi.c。
CONFIG_SCSI：您必须配置至少一个非MTD分区类型。
- NETWORK Support (PCI):
CONFIG_E1000_SPI
Utility code for direct access to the SPI bus on Intel 8257x.
This does not do anything useful unless you set at least one
of CONFIG_CMD_E1000 or CONFIG_E1000_SPI_GENERIC.
CONFIG_NATSEMI
Support for National dp83815 chips.
CONFIG_NS8382X
Support for National dp8382[01] gigabit chips.
CONFIG_E1000_SPI：这是用于直接访问Intel 8257x上的SPI总线的实用程序代码。除非设置了至少一个 CONFIG_CMD_E1000 或 CONFIG_E1000_SPI_GENERIC，否则此选项不会执行任何有用的操作。
CONFIG_NATSEMI：这是对National dp83815芯片的支持。
CONFIG_NS8382X：这是对National dp8382[01]千兆位芯片的支持。
- NETWORK Support (other):
CONFIG_CALXEDA_XGMAC
Support for the Calxeda XGMAC device
CONFIG_LAN91C96
Support for SMSC's LAN91C96 chips.
CONFIG_LAN91C96_USE_32_BIT
Define this to enable 32 bit addressing
CONFIG_SYS_DAVINCI_EMAC_PHY_COUNT
Define this if you have more then 3 PHYs.
CONFIG_FTGMAC100
Support for Faraday's FTGMAC100 Gigabit SoC Ethernet
CONFIG_FTGMAC100_EGIGA
Define this to use GE link update with gigabit PHY.
Define this if FTGMAC100 is connected to gigabit PHY.
If your system has 10/100 PHY only, it might not occur
wrong behavior. Because PHY usually return timeout or
useless data when polling gigabit status and gigabit
control registers. This behavior won't affect the
correctnessof 10/100 link speed update.
CONFIG_SH_ETHER
Support for Renesas on-chip Ethernet controller
CONFIG_SH_ETHER_USE_PORT
Define the number of ports to be used
CONFIG_SH_ETHER_PHY_ADDR
Define the ETH PHY's address
CONFIG_SH_ETHER_CACHE_WRITEBACK
If this option is set, the driver enables cache flush.
CONFIG_CALXEDA_XGMAC: 支持Calxeda XGMAC设备。Calxeda是一家已经关闭的公司，他们曾经设计了一些用于嵌入式系统的网络芯片。
CONFIG_LAN91C96: 支持SMSC的LAN91C96芯片。这是一种早期的以太网芯片，通常在嵌入式系统中使用。
CONFIG_LAN91C96_USE_32_BIT: 定义此选项以启用32位寻址。这通常用于访问更大量的内存。
CONFIG_SYS_DAVINCI_EMAC_PHY_COUNT: 定义此选项如果有超过3个PHY。PHY是物理接口，通常用于连接网卡到网络。
CONFIG_FTGMAC100: 支持Faraday的FTGMAC100千兆位SoC以太网。Faraday是一家生产网络设备的公司。
CONFIG_FTGMAC100_EGIGA: 定义此选项以使用GE链接更新与千兆位PHY。如果FTGMAC100连接到千兆位PHY，则定义此选项。如果系统只有10/100 PHY，它可能不会出现错误行为。因为PHY通常在轮询千兆位状态和千兆位控制寄存器时返回超时或无用的数据。这不会影响10/100链接速度更新的正确性。
CONFIG_SH_ETHER: 支持Renesas片上以太网控制器。Renesas是一家生产半导体产品的公司。
CONFIG_SH_ETHER_USE_PORT: 定义要使用的端口数。
CONFIG_SH_ETHER_PHY_ADDR: 定义ETH PHY的地址。PHY是物理接口，用于连接网卡到网络。
CONFIG_SH_ETHER_CACHE_WRITEBACK: 如果设置了此选项，驱动程序将启用缓存刷新。这意味着在修改内存后，U-Boot将确保这些更改被写入到更永久的存储中（例如硬盘）。
- TPM Support:
CONFIG_TPM
Support TPM devices.
CONFIG_TPM_TIS_INFINEON
Support for Infineon i2c bus TPM devices. Only one device
per system is supported at this time.
CONFIG_TPM_TIS_I2C_BURST_LIMITATION
Define the burst count bytes upper limit
CONFIG_TPM_ST33ZP24
Support for STMicroelectronics TPM devices. Requires DM_TPM support.
CONFIG_TPM_ST33ZP24_I2C
Support for STMicroelectronics ST33ZP24 I2C devices.
Requires TPM_ST33ZP24 and I2C.
CONFIG_TPM_ST33ZP24_SPI
Support for STMicroelectronics ST33ZP24 SPI devices.
Requires TPM_ST33ZP24 and SPI.
CONFIG_TPM_ATMEL_TWI
Support for Atmel TWI TPM device. Requires I2C support.
CONFIG_TPM_TIS_LPC
Support for generic parallel port TPM devices. Only one device
per system is supported at this time.
CONFIG_TPM_TIS_BASE_ADDRESS
Base address where the generic TPM device is mapped
to. Contemporary x86 systems usually map it at
0xfed40000.
CONFIG_TPM
Define this to enable the TPM support library which provides
functional interfaces to some TPM commands.
Requires support for a TPM device.
CONFIG_TPM_AUTH_SESSIONS
Define this to enable authorized functions in the TPM library.
Requires CONFIG_TPM and CONFIG_SHA1.
TPM（受信任的平台模块）的支持选项。TPM是一个用于提供加密密钥的设备，常用于安全启动和身份验证。以下是关于每个配置选项的解释：
CONFIG_TPM: 启用TPM设备支持。
CONFIG_TPM_TIS_INFINEON: 支持Infineon i2c总线的TPM设备。目前每个系统只支持一个此类设备。
CONFIG_TPM_TIS_I2C_BURST_LIMITATION: 定义i2c突发传输的上限字节数。
CONFIG_TPM_ST33ZP24: 支持STMicroelectronics的TPM设备。需要DM_TPM支持。
CONFIG_TPM_ST33ZP24_I2C: 支持STMicroelectronics ST33ZP24 I2C设备。需要TPM_ST33ZP24和I2C支持。
CONFIG_TPM_ST33ZP24_SPI: 支持STMicroelectronics ST33ZP24 SPI设备。需要TPM_ST33ZP24和SPI支持。
CONFIG_TPM_ATMEL_TWI: 支持Atmel TWI TPM设备。需要I2C支持。
CONFIG_TPM_TIS_LPC: 支持通用的并行端口TPM设备。每个系统只支持一个此类设备。
CONFIG_TPM_TIS_BASE_ADDRESS: 通用TPM设备映射的基地址。当代x86系统通常将其映射在0xfed40000。
CONFIG_TPM: 定义此选项以启用TPM支持库，该库为某些TPM命令提供了功能接口。需要支持一个TPM设备。
CONFIG_TPM_AUTH_SESSIONS: 定义此选项以启用TPM库中的授权功能。需要CONFIG_TPM和CONFIG_SHA1支持。
- USB Support:
At the moment only the UHCI host controller is
supported (PIP405, MIP405); define
CONFIG_USB_UHCI to enable it.
define CONFIG_USB_KEYBOARD to enable the USB Keyboard
and define CONFIG_USB_STORAGE to enable the USB
storage devices.
Note:
Supported are USB Keyboards and USB Floppy drives
(TEAC FD-05PUB).
CONFIG_USB_DWC2_REG_ADDR the physical CPU address of the DWC2
HW module registers.
CONFIG_USB_UHCI: 这是一个关于USB主机控制器的配置选项。目前仅支持UHCI（Universal Host Controller Interface，通用主机控制器接口）。如果你想启用UHCI主机控制器，需要定义这个选项。
CONFIG_USB_KEYBOARD: 这是一个关于USB键盘的配置选项。如果你想启用USB键盘支持，需要定义这个选项。
CONFIG_USB_STORAGE: 这是一个关于USB存储设备的配置选项。如果你想启用USB存储设备支持，需要定义这个选项。
CONFIG_USB_DWC2_REG_ADDR: 这是一个关于DWC2（DesignWare USB 2.0 Hub Controller）物理CPU地址的配置选项。这是为了定位DWC2硬件模块的寄存器地址。
- USB Device:
Define the below if you wish to use the USB console.
Once firmware is rebuilt from a serial console issue the
command "setenv stdin usbtty; setenv stdout usbtty" and
attach your USB cable. The Unix command "dmesg" should print
it has found a new device. The environment variable usbtty
can be set to gserial or cdc_acm to enable your device to
appear to a USB host as a Linux gserial device or a
Common Device Class Abstract Control Model serial device.
If you select usbtty = gserial you should be able to enumerate
a Linux host by
# modprobe usbserial vendor=0xVendorID product=0xProductID
else if using cdc_acm, simply setting the environment
variable usbtty to be cdc_acm should suffice. The following
might be defined in YourBoardName.h
一旦你通过串行控制台重新构建了固件，你需要发出"setenv stdin usbtty; setenv stdout usbtty"这个命令，
然后连接USB电缆。Unix命令"dmesg"应该会打印出发现新设备的消息。环境变量usbtty可以设置为gserial或cdc_acm，
使你的设备在USB主机上显示为Linux gserial设备或通用设备类抽象控制模型串行设备。如果你选择usbtty = gserial，
你应该可以通过运行命令"# modprobe usbserial vendor=0xVendorID product=0xProductID"枚举Linux主机。如果使用cdc_acm，
只需将环境变量usbtty设置为cdc_acm就足够了。以下可能在YourBoardName.h文件中定义：
CONFIG_USB_DEVICE
Define this to build a UDC device
CONFIG_USB_TTY
Define this to have a tty type of device available to
talk to the UDC device
CONFIG_USBD_HS
Define this to enable the high speed support for usb
device and usbtty. If this feature is enabled, a routine
int is_usbd_high_speed(void)
also needs to be defined by the driver to dynamically poll
whether the enumeration has succeded at high speed or full
speed.
CONFIG_USB_DEVICE: 如果你想构建一个USB设备（UDC），你需要定义这个选项。UDC代表USB设备控制器，负责管理USB设备与主机之间的通信。
CONFIG_USB_TTY: 如果你想使用tty类型的设备来与UDC设备通信，你需要定义这个选项。tty是Linux中的一种设备类型，常用于串行通信。
CONFIG_USBD_HS: 如果你想启用对USB设备和usbtty的高速度支持，你需要定义这个选项。如果此功能被启用，还需要定义一个名为int is_usbd_high_speed(void)的例程，以动态检查枚举是否在高速或全速下成功。
If you have a USB-IF assigned VendorID then you may wish to
define your own vendor specific values either in BoardName.h
or directly in usbd_vendor_info.h. If you don't define
CONFIG_USBD_MANUFACTURER, CONFIG_USBD_PRODUCT_NAME,
CONFIG_USBD_VENDORID and CONFIG_USBD_PRODUCTID, then U-Boot
should pretend to be a Linux device to it's target host.
CONFIG_USBD_MANUFACTURER
Define this string as the name of your company for
- CONFIG_USBD_MANUFACTURER "my company"
CONFIG_USBD_PRODUCT_NAME
Define this string as the name of your product
- CONFIG_USBD_PRODUCT_NAME "acme usb device"
CONFIG_USBD_VENDORID
Define this as your assigned Vendor ID from the USB
Implementors Forum. This *must* be a genuine Vendor ID
to avoid polluting the USB namespace.
- CONFIG_USBD_VENDORID 0xFFFF
CONFIG_USBD_PRODUCTID
Define this as the unique Product ID
for your device
- CONFIG_USBD_PRODUCTID 0xFFFF
如果你有一个USB-IF分配的Vendor ID，那么你可能希望在BoardName.h或直接在usbd_vendor_info.h文件中定义你自己的厂商特定值。
如果你不定义CONFIG_USBD_MANUFACTURER、CONFIG_USBD_PRODUCT_NAME、CONFIG_USBD_VENDORID和CONFIG_USBD_PRODUCTID，那么U-Boot应该假装成一个Linux设备对其目标主机进行通信。
CONFIG_USBD_MANUFACTURER
将此字符串定义为贵公司的名称，例如：CONFIG_USBD_MANUFACTURER "my company"
CONFIG_USBD_PRODUCT_NAME
将此字符串定义为你的产品名称，例如：CONFIG_USBD_PRODUCT_NAME "acme usb device"
CONFIG_USBD_VENDORID
将此定义为从USB实施者论坛分配给你的Vendor ID。这必须是一个真正的Vendor ID，以避免污染USB命名空间。例如：CONFIG_USBD_VENDORID 0xFFFF
CONFIG_USBD_PRODUCTID
将此定义为你的设备唯一的Product ID，例如：CONFIG_USBD_PRODUCTID 0xFFFF
- ULPI Layer Support:
The ULPI (UTMI Low Pin (count) Interface) PHYs are supported via
the generic ULPI layer. The generic layer accesses the ULPI PHY
via the platform viewport, so you need both the genric layer and
the viewport enabled. Currently only Chipidea/ARC based
viewport is supported.
To enable the ULPI layer support, define CONFIG_USB_ULPI and
CONFIG_USB_ULPI_VIEWPORT in your board configuration file.
If your ULPI phy needs a different reference clock than the
standard 24 MHz then you have to define CONFIG_ULPI_REF_CLK to
the appropriate value in Hz.
ULPI（UTMI低针脚（计数）接口）PHY通过通用ULPI层得到支持。通用层通过平台视区访问ULPI PHY，因此您需要同时启用通用层和视区。目前仅支持基于Chipidea/ARC的视区。
要启用ULPI层支持，请在您的板配置文件中定义CONFIG_USB_ULPI和CONFIG_USB_ULPI_VIEWPORT。如果您的ULPI phy需要不同于标准24 MHz的参考时钟，则必须将CONFIG_ULPI_REF_CLK定义为适当的Hz值。
- MMC Support:
CONFIG_SH_MMCIF
Support for Renesas on-chip MMCIF controller
CONFIG_SH_MMCIF_ADDR
Define the base address of MMCIF registers
CONFIG_SH_MMCIF_CLK
Define the clock frequency for MMCIF
CONFIG_SH_MMCIF：支持 Renesas 芯片上的 MMCIF 控制器。
CONFIG_SH_MMCIF_ADDR：定义 MMCIF 寄存器的基地址。
CONFIG_SH_MMCIF_CLK：定义 MMCIF 的时钟频率。
- USB Device Firmware Update (DFU) class support:
CONFIG_DFU_OVER_USB
This enables the USB portion of the DFU USB class
CONFIG_DFU_NAND
This enables support for exposing NAND devices via DFU.
CONFIG_DFU_RAM
This enables support for exposing RAM via DFU.
Note: DFU spec refer to non-volatile memory usage, but
allow usages beyond the scope of spec - here RAM usage,
one that would help mostly the developer.
CONFIG_SYS_DFU_DATA_BUF_SIZE
Dfu transfer uses a buffer before writing data to the
raw storage device. Make the size (in bytes) of this buffer
configurable. The size of this buffer is also configurable
through the "dfu_bufsiz" environment variable.
CONFIG_SYS_DFU_MAX_FILE_SIZE
When updating files rather than the raw storage device,
we use a static buffer to copy the file into and then write
the buffer once we've been given the whole file. Define
this to the maximum filesize (in bytes) for the buffer.
Default is 4 MiB if undefined.
DFU_DEFAULT_POLL_TIMEOUT
Poll timeout [ms], is the timeout a device can send to the
host. The host must wait for this timeout before sending
a subsequent DFU_GET_STATUS request to the device.
DFU_MANIFEST_POLL_TIMEOUT
Poll timeout [ms], which the device sends to the host when
entering dfuMANIFEST state. Host waits this timeout, before
sending again an USB request to the device.
USB设备固件更新（DFU）类支持：
CONFIG_DFU_OVER_USB：启用DFU USB类的USB部分。
CONFIG_DFU_NAND：支持通过DFU公开NAND设备。
CONFIG_DFU_RAM：支持通过DFU公开RAM。注意：DFU规范提到非易失性存储器的使用，但也允许超出规范范围的使用-此处是指RAM的使用，这对开发人员非常有帮助。
CONFIG_SYS_DFU_DATA_BUF_SIZE：在将数据写入原始存储设备之前，DFU传输使用一个缓冲区。使缓冲区的大小（以字节为单位）可配置。此缓冲区的大小也可以通过“dfu_bufsiz”环境变量进行配置。
CONFIG_SYS_DFU_MAX_FILE_SIZE：在更新文件而不是原始存储设备时，我们使用一个静态缓冲区将文件复制到其中，然后在收到整个文件后一次性写入缓冲区。定义此参数为缓冲区的最大文件大小（以字节为单位）。如果未定义，默认值为4 MiB。
DFU_DEFAULT_POLL_TIMEOUT：轮询超时[ms]，是设备可以发送给主机的超时。主机必须在此超时之前等待，才能向设备发送随后的DFU_GET_STATUS请求。
DFU_MANIFEST_POLL_TIMEOUT：轮询超时[ms]，设备在进入dfuMANIFEST状态时发送给主机的超时。主机在发送另一个USB请求到设备之前等待此超时。
- Journaling Flash filesystem support:
CONFIG_SYS_JFFS2_FIRST_SECTOR,
CONFIG_SYS_JFFS2_FIRST_BANK, CONFIG_SYS_JFFS2_NUM_BANKS
Define these for a default partition on a NOR device
日志闪存文件系统的支持:
CONFIG_SYS_JFFS2_FIRST_SECTOR,
CONFIG_SYS_JFFS2_FIRST_BANK, CONFIG_SYS_JFFS2_NUM_BANKS
为NOR设备上的默认分区定义这些参数。
- Keyboard Support:
See Kconfig help for available keyboard drivers.
- MII/PHY support:
CONFIG_PHY_CLOCK_FREQ (ppc4xx)
The clock frequency of the MII bus
CONFIG_PHY_CMD_DELAY (ppc4xx)
Some PHY like Intel LXT971A need extra delay after
command issued before MII status register can be read
MII/PHY支持：
CONFIG_PHY_CLOCK_FREQ (ppc4xx)
MII总线的时钟频率。
CONFIG_PHY_CMD_DELAY (ppc4xx)
某些PHY（如Intel LXT971A）在命令发出后需要额外的延迟才能读取MII状态寄存器。
- IP address:
CONFIG_IPADDR
Define a default value for the IP address to use for
the default Ethernet interface, in case this is not
determined through e.g. bootp.
(Environment variable "ipaddr")
为默认的以太网接口定义一个默认的IP地址，以防不能通过例如bootp来决定。
（环境变量 "ipaddr"）
- Server IP address:
CONFIG_SERVERIP
Defines a default value for the IP address of a TFTP
server to contact when using the "tftboot" command.
(Environment variable "serverip")
为使用“tftboot”命令时需要联系的TFTP服务器的IP地址定义一个默认值。
（环境变量 "serverip"）
- Gateway IP address:
CONFIG_GATEWAYIP
Defines a default value for the IP address of the
default router where packets to other networks are
sent to.
(Environment variable "gatewayip")
为默认路由器定义一个默认的IP地址，发送到其他网络的包将发送到该路由器。
（环境变量 "gatewayip"）
- Subnet mask:
CONFIG_NETMASK
Defines a default value for the subnet mask (or
routing prefix) which is used to determine if an IP
address belongs to the local subnet or needs to be
forwarded through a router.
(Environment variable "netmask")
为子网掩码（或路由前缀）定义默认值，用于确定IP地址是否属于本地子网，或需要通过路由器进行转发。
（环境变量 "netmask"）
- BOOTP Recovery Mode:
CONFIG_BOOTP_RANDOM_DELAY
If you have many targets in a network that try to
boot using BOOTP, you may want to avoid that all
systems send out BOOTP requests at precisely the same
moment (which would happen for instance at recovery
from a power failure, when all systems will try to
boot, thus flooding the BOOTP server. Defining
CONFIG_BOOTP_RANDOM_DELAY causes a random delay to be
inserted before sending out BOOTP requests. The
following delays are inserted then:
1st BOOTP request: delay 0 ... 1 sec
2nd BOOTP request: delay 0 ... 2 sec
3rd BOOTP request: delay 0 ... 4 sec
4th and following
BOOTP requests: delay 0 ... 8 sec
CONFIG_BOOTP_ID_CACHE_SIZE
BOOTP packets are uniquely identified using a 32-bit ID. The
server will copy the ID from client requests to responses and
U-Boot will use this to determine if it is the destination of
an incoming response. Some servers will check that addresses
aren't in use before handing them out (usually using an ARP
ping) and therefore take up to a few hundred milliseconds to
respond. Network congestion may also influence the time it
takes for a response to make it back to the client. If that
time is too long, U-Boot will retransmit requests. In order
to allow earlier responses to still be accepted after these
retransmissions, U-Boot's BOOTP client keeps a small cache of
IDs. The CONFIG_BOOTP_ID_CACHE_SIZE controls the size of this
cache. The default is to keep IDs for up to four outstanding
requests. Increasing this will allow U-Boot to accept offers
from a BOOTP client in networks with unusually high latency.
BOOTP恢复模式：
CONFIG_BOOTP_RANDOM_DELAY
如果您在网络中有许多目标尝试使用BOOTP进行引导，则可能希望避免所有系统在同一时刻发送BOOTP请求（例如，在从电源故障中恢复时，所有系统都将尝试引导，从而淹没BOOTP服务器）。
定义CONFIG_BOOTP_RANDOM_DELAY会在发送BOOTP请求之前插入随机延迟。接着会插入以下延迟：
第一个BOOTP请求：延迟0到1秒
第二个BOOTP请求：延迟0到2秒
第三个BOOTP请求：延迟0到4秒
四个及以后的BOOTP请求：延迟0到8秒
CONFIG_BOOTP_ID_CACHE_SIZE
BOOTP数据包使用32位ID进行唯一标识。服务器将从客户端请求中复制ID到响应中，U-Boot将使用此ID来确定是否是传入响应的目标。
某些服务器将在分配地址之前检查地址是否正在被使用（通常使用ARP ping）并且因此需要长达几百毫秒才能响应。网络拥塞也可能影响响应返回客户端的时间。
如果响应时间太长，U-Boot将重新传输请求。为了在这些重新传输之后仍然允许更早的响应被接受，U-Boot的BOOTP客户端保留了一个小ID缓存。CONFIG_BOOTP_ID_CACHE_SIZE控制此缓存的大小。
默认情况下，保留最多四个未完成的请求的ID。增加此值将允许U-Boot接受具有异常高延迟的网络中的BOOTP客户端的提供。
- DHCP Advanced Options:
DHCP高级选项：
- Link-local IP address negotiation:
Negotiate with other link-local clients on the local network
for an address that doesn't require explicit configuration.
This is especially useful if a DHCP server cannot be guaranteed
to exist in all environments that the device must operate.
See doc/README.link-local for more information.
链路本地IP地址谈判：
与本地网络上的其他链路本地客户端进行谈判，以获得不需要显式配置的地址。
如果不能保证在设备必须运行的所有环境中都存在DHCP服务器，这特别有用。
更多信息，请参阅doc/README.link-local。
- MAC address from environment variables
FDT_SEQ_MACADDR_FROM_ENV
Fix-up device tree with MAC addresses fetched sequentially from
environment variables. This config work on assumption that
non-usable ethernet node of device-tree are either not present
or their status has been marked as "disabled".
从环境变量获取MAC地址
FDT_SEQ_MACADDR_FROM_ENV
使用从环境变量获取的MAC地址修复设备树。此配置工作基于假设，设备树中不可用的以太网节点要么不存在，要么其状态已标记为“禁用”。
CDP选项：
- CDP Options:
CONFIG_CDP_DEVICE_ID
The device id used in CDP trigger frames.
CONFIG_CDP_DEVICE_ID_PREFIX
A two character string which is prefixed to the MAC address
of the device.
CONFIG_CDP_PORT_ID
A printf format string which contains the ascii name of
the port. Normally is set to "eth%d" which sets
eth0 for the first Ethernet, eth1 for the second etc.
CONFIG_CDP_CAPABILITIES
A 32bit integer which indicates the device capabilities;
0x00000010 for a normal host which does not forwards.
CONFIG_CDP_VERSION
An ascii string containing the version of the software.
CONFIG_CDP_PLATFORM
An ascii string containing the name of the platform.
CONFIG_CDP_TRIGGER
A 32bit integer sent on the trigger.
CONFIG_CDP_POWER_CONSUMPTION
A 16bit integer containing the power consumption of the
device in .1 of milliwatts.
CONFIG_CDP_APPLIANCE_VLAN_TYPE
A byte containing the id of the VLAN.
CDP选项：
CONFIG_CDP_DEVICE_ID 在CDP触发帧中使用的设备ID。
CONFIG_CDP_DEVICE_ID_PREFIX 一个由两个字符组成的字符串，该字符串将添加到设备的MAC地址前。
CONFIG_CDP_PORT_ID 一个printf格式字符串，包含该端口的ASCII名称。通常设置为“eth%d”，其中“eth0”表示第一个以太网端口，“eth1”表示第二个以太网端口等。
CONFIG_CDP_CAPABILITIES 一个32位整数，表示设备的32位整数，指示设备的功能；0x00000010表示正常主机，不进行数据包转发。
CONFIG_CDP_VERSION 一个ASCII字符串，包含该软件的版本信息。
CONFIG_CDP_PLATFORM 一个ASCII字符串，包含运行该软件的平台的名称。
CONFIG_CDP_TRIGGER 一个32位整数，在触发时发送。
CONFIG_CDP_POWER_CONSUMPTION 一个16位整数，包含设备的功率消耗（以0.1毫瓦为单位）。
CONFIG_CDP_APPLIANCE_VLAN_TYPE 一个字节，包含VLAN的ID。
- Status LED: CONFIG_LED_STATUS
Several configurations allow to display the current
status using a LED. For instance, the LED will blink
fast while running U-Boot code, stop blinking as
soon as a reply to a BOOTP request was received, and
start blinking slow once the Linux kernel is running
(supported by a status LED driver in the Linux
kernel). Defining CONFIG_LED_STATUS enables this
feature in U-Boot.
Additional options:
CONFIG_LED_STATUS_GPIO
The status LED can be connected to a GPIO pin.
In such cases, the gpio_led driver can be used as a
status LED backend implementation. Define CONFIG_LED_STATUS_GPIO
to include the gpio_led driver in the U-Boot binary.
CONFIG_GPIO_LED_INVERTED_TABLE
Some GPIO connected LEDs may have inverted polarity in which
case the GPIO high value corresponds to LED off state and
GPIO low value corresponds to LED on state.
In such cases CONFIG_GPIO_LED_INVERTED_TABLE may be defined
with a list of GPIO LEDs that have inverted polarity.
状态LED：CONFIG_LED_STATUS
U-Boot提供了一些配置选项，以便使用LED显示当前状态。例如，在运行U-Boot代码时，LED会快速闪烁；一旦收到BOOTP请求的回复，LED将停止闪烁；
一旦Linux内核开始运行，LED将开始缓慢闪烁（由Linux内核中的状态LED驱动程序支持）。定义CONFIG_LED_STATUS选项可以在U-Boot中启用此功能。
其他选项：
CONFIG_LED_STATUS_GPIO
状态LED可以连接到GPIO引脚。在这种情况下，可以使用gpio_led驱动程序作为状态LED的后端实现。定义CONFIG_LED_STATUS_GPIO以将gpio_led驱动程序包含在U-Boot二进制文件中。
CONFIG_GPIO_LED_INVERTED_TABLE
一些GPIO连接的LED可能具有反转极性，在这种情况下，GPIO高值对应于LED关闭状态，而GPIO低值对应于LED打开状态。在这种情况下，可以定义CONFIG_GPIO_LED_INVERTED_TABLE，并使用具有反转极性的GPIO LED列表。
- I2C Support:
CONFIG_SYS_NUM_I2C_BUSES
Hold the number of i2c buses you want to use.
CONFIG_SYS_I2C_DIRECT_BUS
define this, if you don't use i2c muxes on your hardware.
if CONFIG_SYS_I2C_MAX_HOPS is not defined or == 0 you can
omit this define.
CONFIG_SYS_I2C_MAX_HOPS
define how many muxes are maximal consecutively connected
on one i2c bus. If you not use i2c muxes, omit this
define.
CONFIG_SYS_I2C_BUSES
hold a list of buses you want to use, only used if
CONFIG_SYS_I2C_DIRECT_BUS is not defined, for example
a board with CONFIG_SYS_I2C_MAX_HOPS = 1 and
CONFIG_SYS_NUM_I2C_BUSES = 9:
CONFIG_SYS_I2C_BUSES {{0, {I2C_NULL_HOP}}, \
{0, {{I2C_MUX_PCA9547, 0x70, 1}}}, \
{0, {{I2C_MUX_PCA9547, 0x70, 2}}}, \
{0, {{I2C_MUX_PCA9547, 0x70, 3}}}, \
{0, {{I2C_MUX_PCA9547, 0x70, 4}}}, \
{0, {{I2C_MUX_PCA9547, 0x70, 5}}}, \
{1, {I2C_NULL_HOP}}, \
{1, {{I2C_MUX_PCA9544, 0x72, 1}}}, \
{1, {{I2C_MUX_PCA9544, 0x72, 2}}}, \
}
which defines
bus 0 on adapter 0 without a mux
bus 1 on adapter 0 with a PCA9547 on address 0x70 port 1
bus 2 on adapter 0 with a PCA9547 on address 0x70 port 2
bus 3 on adapter 0 with a PCA9547 on address 0x70 port 3
bus 4 on adapter 0 with a PCA9547 on address 0x70 port 4
bus 5 on adapter 0 with a PCA9547 on address 0x70 port 5
bus 6 on adapter 1 without a mux
bus 7 on adapter 1 with a PCA9544 on address 0x72 port 1
bus 8 on adapter 1 with a PCA9544 on address 0x72 port 2
If you do not have i2c muxes on your board, omit this define.
I2C支持：
CONFIG_SYS_NUM_I2C_BUSES：定义要使用的I2C总线数量。
CONFIG_SYS_I2C_DIRECT_BUS：如果你的硬件上没有使用I2C多路复用器，则需要定义这个选项。如果未定义CONFIG_SYS_I2C_MAX_HOPS或CONFIG_SYS_I2C_MAX_HOPS == 0，则可以忽略此定义。
CONFIG_SYS_I2C_MAX_HOPS：定义在一条I2C总线上最大连续连接的多路复用器数量。如果不使用I2C多路复用器，请忽略此定义。
CONFIG_SYS_I2C_BUSES：列出要使用的总线，仅在未定义CONFIG_SYS_I2C_DIRECT_BUS时使用，例如CONFIG_SYS_I2C_MAX_HOPS = 1和CONFIG_SYS_NUM_I2C_BUSES = 9的板：
CONFIG_SYS_I2C_BUSES {{0, {I2C_NULL_HOP}}, \
{0, {{I2C_MUX_PCA9547, 0x70, 1}}}, \
{0, {{I2C_MUX_PCA9547, 0x70, 2}}}, \
{0, {{I2C_MUX_PCA9547, 0x70, 3}}}, \
{0, {{I2C_MUX_PCA9547, 0x70, 4}}}, \
{0, {{I2C_MUX_PCA9547, 0x70, 5}}}, \
{1, {I2C_NULL_HOP}}, \
{1, {{I2C_MUX_PCA9544, 0x72, 1}}}, \
{1, {{I2C_MUX_PCA9544, 0x72, 2}}}, \
}
定义了：
总线0在适配器0上没有多路复用器；
总线1在适配器0上使用PCA9547，地址为0x70，端口为1；
总线2在适配器0上使用PCA9547，地址为0x70，端口为2；
总线3在适配器0上使用PCA9547，地址为0x70，端口为3；
总线4在适配器0上使用PCA9547，地址为0x70，端口为4；
总线5在适配器0上使用PCA9547，地址为0x70，端口为5；
总线6在适配器1上没有多路复用器；
总线7在适配器1上使用PCA9544，地址为0x72，端口为1；
总线8在适配器1上使用PCA9544，地址为0x72，端口为2；
如果在你的板子上没有I2C多路复用器，请忽略此定义。
- Legacy I2C Support:
If you use the software i2c interface (CONFIG_SYS_I2C_SOFT)
then the following macros need to be defined (examples are
from include/configs/lwmon.h):
I2C_INIT
(Optional). Any commands necessary to enable the I2C
controller or configure ports.
eg: #define I2C_INIT (immr->im_cpm.cp_pbdir |= PB_SCL)
I2C_ACTIVE
The code necessary to make the I2C data line active
(driven). If the data line is open collector, this
define can be null.
eg: #define I2C_ACTIVE (immr->im_cpm.cp_pbdir |= PB_SDA)
I2C_TRISTATE
The code necessary to make the I2C data line tri-stated
(inactive). If the data line is open collector, this
define can be null.
eg: #define I2C_TRISTATE (immr->im_cpm.cp_pbdir &= ~PB_SDA)
I2C_READ
Code that returns true if the I2C data line is high,
false if it is low.
eg: #define I2C_READ ((immr->im_cpm.cp_pbdat & PB_SDA) != 0)
I2C_SDA(bit)
If <bit> is true, sets the I2C data line high. If it
is false, it clears it (low).
eg: #define I2C_SDA(bit) \
if(bit) immr->im_cpm.cp_pbdat |= PB_SDA; \
else immr->im_cpm.cp_pbdat &= ~PB_SDA
I2C_SCL(bit)
If <bit> is true, sets the I2C clock line high. If it
is false, it clears it (low).
eg: #define I2C_SCL(bit) \
if(bit) immr->im_cpm.cp_pbdat |= PB_SCL; \
else immr->im_cpm.cp_pbdat &= ~PB_SCL
I2C_DELAY
This delay is invoked four times per clock cycle so this
controls the rate of data transfer. The data rate thus
is 1 / (I2C_DELAY * 4). Often defined to be something
like:
#define I2C_DELAY udelay(2)
CONFIG_SOFT_I2C_GPIO_SCL / CONFIG_SOFT_I2C_GPIO_SDA
If your arch supports the generic GPIO framework (asm/gpio.h),
then you may alternatively define the two GPIOs that are to be
used as SCL / SDA. Any of the previous I2C_xxx macros will
have GPIO-based defaults assigned to them as appropriate.
You should define these to the GPIO value as given directly to
the generic GPIO functions.
CONFIG_SYS_I2C_INIT_BOARD
When a board is reset during an i2c bus transfer
chips might think that the current transfer is still
in progress. On some boards it is possible to access
the i2c SCLK line directly, either by using the
processor pin as a GPIO or by having a second pin
connected to the bus. If this option is defined a
custom i2c_init_board() routine in boards/xxx/board.c
is run early in the boot sequence.
CONFIG_I2C_MULTI_BUS
This option allows the use of multiple I2C buses, each of which
must have a controller. At any point in time, only one bus is
active. To switch to a different bus, use the 'i2c dev' command.
Note that bus numbering is zero-based.
CONFIG_SYS_I2C_NOPROBES
This option specifies a list of I2C devices that will be skipped
when the 'i2c probe' command is issued. If CONFIG_I2C_MULTI_BUS
is set, specify a list of bus-device pairs. Otherwise, specify
a 1D array of device addresses
e.g.
#undef CONFIG_I2C_MULTI_BUS
#define CONFIG_SYS_I2C_NOPROBES {0x50,0x68}
will skip addresses 0x50 and 0x68 on a board with one I2C bus
#define CONFIG_I2C_MULTI_BUS
#define CONFIG_SYS_I2C_NOPROBES {{0,0x50},{0,0x68},{1,0x54}}
will skip addresses 0x50 and 0x68 on bus 0 and address 0x54 on bus 1
CONFIG_SYS_RTC_BUS_NUM
If defined, then this indicates the I2C bus number for the RTC.
If not defined, then U-Boot assumes that RTC is on I2C bus 0.
CONFIG_SOFT_I2C_READ_REPEATED_START
defining this will force the i2c_read() function in
the soft_i2c driver to perform an I2C repeated start
between writing the address pointer and reading the
data. If this define is omitted the default behaviour
of doing a stop-start sequence will be used. Most I2C
devices can use either method, but some require one or
the other.
传统I2C支持：
如果你使用的是软件i2c接口（CONFIG_SYS_I2C_SOFT），则需要定义以下宏（示例来自include/configs/lwmon.h）：
I2C_INIT
（可选）。启用I2C控制器或配置端口的必要命令。
例如：#define I2C_INIT (immr->im_cpm.cp_pbdir |= PB_SCL)
I2C_ACTIVE
使I2C数据线活动（驱动）所需代码。如果数据线为开集电极，则此定义可以为空。
例如：#define I2C_ACTIVE (immr->im_cpm.cp_pbdir |= PB_SDA)
I2C_TRISTATE
使I2C数据线三态（不活动）所需代码。如果数据线为开集电极，则此定义可以为空。
例如：#define I2C_TRISTATE (immr->im_cpm.cp_pbdir &= ~PB_SDA)
I2C_READ
返回true如果I2C数据线高，返回false如果低。
例如：#define I2C_READ ((immr->im_cpm.cp_pbdat & PB_SDA) != 0)
I2C_SDA(bit)
如果<bit>为真，则将I2C数据线设为高。如果为假，则将其清除（低）。
例如：#define I2C_SDA(bit) \
if(bit) immr->im_cpm.cp_pbdat |= PB_SDA; \
else immr->im_cpm.cp_pbdat &= ~PB_SDA
I2C_SCL（bit）
如果 <bit> 为 true，则将 I2C 时钟线设置为高。如果它
如果为假，则清除它（低）。
例如：#define I2C_SCL(bit) \
if(bit) immr->im_cpm.cp_pbdat |= PB_SCL; \
else，immr->im_cpm.cp_pbdat &= ~PB_SCL
I2C_DELAY（I2C延时）
每个时钟周期调用四次此延迟，因此
控制数据传输速率。数据速率因此
是 1 / (I2C_DELAY * 4)。通常定义为
例如：
#define I2C_DELAY 2
CONFIG_SOFT_I2C_GPIO_SCL / CONFIG_SOFT_I2C_GPIO_SDA
如果你的体系结构支持通用 GPIO 框架（asm/gpio.h），
那么你也可以定义两个 GPIO，用作 SCL / SDA。
前面的任何 I2C_xxx 宏都将根据需要为其分配基于 GPIO 的默认值。
您应该将这些定义为 GPIO 值，如直接提供给通用 GPIO 函数。
CONFIG_SYS_I2C_INIT_BOARD
当主板在 i2c 总线上传输时被复位，芯片可能认为当前传输仍在进行中。
在一些主板上，可以直接访问 i2c SCLK 线，要么通过将处理器引脚用作 GPIO，要么通过将第二个引脚连接到总线。
如果定义了此选项，则在 boards/xxx/board.c 中的自定义 i2c_init_board() 例程将在引导顺序的早期运行。
CONFIG_I2C_MULTI_BUS
此选项允许使用多个 I2C 总线，每个总线必须具有一个控制器。在任何时候，只有一个总线处于活动状态。要切换到不同的总线，请使用 'i2c dev' 命令。请注意，总线编号是零基的。
CONFIG_SYS_I2C_NOPROBES
此选项指定了当发出 'i2c probe' 命令时要跳过的 I2C 设备列表。
如果设置了 CONFIG_I2C_MULTI_BUS，则指定一个总线-设备对列表。否则，指定一个 1D 设备地址数组。
例如：
makefile
#undef CONFIG_I2C_MULTI_BUS
#define CONFIG_SYS_I2C_NOPROBES {0x50,0x68}
这将在只有一个 I2C 总线的板上跳过地址 0x50 和 0x68
makefile
#define CONFIG_I2C_MULTI_BUS
#define CONFIG_SYS_I2C_NOPROBES {{0,0x50},{0,0x68},{1,0x54}}
这将在总线 0 上跳过地址 0x50 和 0x68，在总线 1 上跳过地址 0x54
CONFIG_SYS_RTC_BUS_NUM
如果定义了，则表示 RTC 的 I2C 总线号。
如果没有定义，则 U-Boot 假定 RTC 在 I2C 总线 0 上。
CONFIG_SOFT_I2C_READ_REPEATED_START
定义此选项将强制软 I2C 驱动程序中的 i2c_read() 函数在写入地址指针和读取数据之间执行 I2C 重复启动。
如果省略此定义，则默认行为是执行停止-启动序列。大多数 I2C 设备可以使用其中一种方法，但有些设备需要使用其中一种或另一种方法。
- SPI Support: CONFIG_SPI
Enables SPI driver (so far only tested with
SPI EEPROM, also an instance works with Crystal A/D and
D/As on the SACSng board)
CONFIG_SYS_SPI_MXC_WAIT
Timeout for waiting until spi transfer completed.
default: (CONFIG_SYS_HZ/100) /* 10 ms */
SPI支持：CONFIG_SPI
启用SPI驱动程序（迄今为止仅在SPI EEPROM上测试过，同时也可以与SACSng板上的Crystal A/D和D/As一起工作）
CONFIG_SYS_SPI_MXC_WAIT
等待SPI传输完成的超时时间。默认：（CONFIG_SYS_HZ/100） /* 10毫秒 */
- FPGA Support: CONFIG_FPGA
Enables FPGA subsystem.
CONFIG_FPGA_<vendor>
Enables support for specific chip vendors.
(ALTERA, XILINX)
CONFIG_FPGA_<family>
Enables support for FPGA family.
(SPARTAN2, SPARTAN3, VIRTEX2, CYCLONE2, ACEX1K, ACEX)
CONFIG_SYS_FPGA_CHECK_BUSY
Enable checks on FPGA configuration interface busy
status by the configuration function. This option
will require a board or device specific function to
be written.
CONFIG_FPGA_DELAY
If defined, a function that provides delays in the FPGA
configuration driver.
CONFIG_SYS_FPGA_CHECK_ERROR
Check for configuration errors during FPGA bitfile
loading. For example, abort during Virtex II
configuration if the INIT_B line goes low (which
indicated a CRC error).
CONFIG_SYS_FPGA_WAIT_INIT
Maximum time to wait for the INIT_B line to de-assert
after PROB_B has been de-asserted during a Virtex II
FPGA configuration sequence. The default time is 500
ms.
CONFIG_SYS_FPGA_WAIT_BUSY
Maximum time to wait for BUSY to de-assert during
Virtex II FPGA configuration. The default is 5 ms.
CONFIG_SYS_FPGA_WAIT_CONFIG
Time to wait after FPGA configuration. The default is
200 ms.
FPGA支持：CONFIG_FPGA
启用FPGA子系统。
CONFIG_FPGA_<vendor> 启用对特定芯片供应商的支持。（ALTERA，XILINX）
CONFIG_FPGA_<family> 启用对FPGA系列的支持。（SPARTAN2，SPARTAN3，VIRTEX2，CYCLONE2，ACEX1K，ACEX）
CONFIG_SYS_FPGA_CHECK_BUSY 通过配置函数启用对FPGA配置接口忙碌状态的检查。此选项将需要编写一个特定于板或设备的函数。
CONFIG_FPGA_DELAY 如果已定义，则为FPGA配置驱动程序提供延迟的函数。
CONFIG_SYS_FPGA_CHECK_ERROR 在加载FPGA bitfile期间检查配置错误。例如，如果INIT_B线变低（表示CRC错误），则在Virtex II配置期间中止。
CONFIG_SYS_FPGA_WAIT_INIT 在Virtex II FPGA配置期间，在PROB_B被解除之后等待INIT_B线解除的最长时间。默认时间为500毫秒。
CONFIG_SYS_FPGA_WAIT_BUSY 在Virtex II FPGA配置期间等待BUSY解除的最长时间。默认是5毫秒。
CONFIG_SYS_FPGA_WAIT_CONFIG FPGA配置后的等待时间。默认是200毫秒。
- Vendor Parameter Protection:
U-Boot considers the values of the environment
variables "serial#" (Board Serial Number) and
"ethaddr" (Ethernet Address) to be parameters that
are set once by the board vendor / manufacturer, and
protects these variables from casual modification by
the user. Once set, these variables are read-only,
and write or delete attempts are rejected. You can
change this behaviour:
If CONFIG_ENV_OVERWRITE is #defined in your config
file, the write protection for vendor parameters is
completely disabled. Anybody can change or delete
these parameters.
Alternatively, if you define _both_ an ethaddr in the
default env _and_ CONFIG_OVERWRITE_ETHADDR_ONCE, a default
Ethernet address is installed in the environment,
which can be changed exactly ONCE by the user. [The
serial# is unaffected by this, i. e. it remains
read-only.]
The same can be accomplished in a more flexible way
for any variable by configuring the type of access
to allow for those variables in the ".flags" variable
or define CONFIG_ENV_FLAGS_LIST_STATIC.
供应商参数保护：
U-Boot将环境变量“serial#”（板序列号）和“ethaddr”（以太网地址）的值视为由板卡供应商/制造商一次性设置的参数，并保护这些变量免受用户随意修改。
一旦设置，这些变量就是只读的，任何写入或删除尝试都会被拒绝。您可以改变这种行为：
如果在您的配置文件中定义了CONFIG_ENV_OVERWRITE，那么供应商参数的写保护将被完全禁用。任何人都可以更改或删除这些参数。
另外，如果您在默认环境中同时定义了ethaddr和ipaddr，并且同时定义了CONFIG_OVERWRITE_ETHADDR_ONCE，
则默认情况下会在环境中安装一个以太网地址，该地址只能由用户更改一次。[serial#不受此影响，即它保持只读。]
对于任何变量，可以通过配置访问类型以更灵活的方式实现这一目标。在“.flags”变量中允许对这些变量进行访问，或者定义CONFIG_ENV_FLAGS_LIST_STATIC。
- Protected RAM:
CONFIG_PRAM
Define this variable to enable the reservation of
"protected RAM", i. e. RAM which is not overwritten
by U-Boot. Define CONFIG_PRAM to hold the number of
kB you want to reserve for pRAM. You can overwrite
this default value by defining an environment
variable "pram" to the number of kB you want to
reserve. Note that the board info structure will
still show the full amount of RAM. If pRAM is
reserved, a new environment variable "mem" will
automatically be defined to hold the amount of
remaining RAM in a form that can be passed as boot
argument to Linux, for instance like that:
setenv bootargs ... mem=\${mem}
saveenv
This way you can tell Linux not to use this memory,
either, which results in a memory region that will
not be affected by reboots.
*WARNING* If your board configuration uses automatic
detection of the RAM size, you must make sure that
this memory test is non-destructive. So far, the
following board configurations are known to be
"pRAM-clean":
IVMS8, IVML24, SPD8xx,
HERMES, IP860, RPXlite, LWMON,
FLAGADM
受保护的RAM：
CONFIG_PRAM
定义此变量以启用对“受保护的RAM”的预留，即不会被U-Boot覆盖的RAM。将CONFIG_PRAM定义为想要为pRAM预留的kB数量。
可以通过定义环境变量“pram”来覆盖此默认值，以指定想要预留的kB数量。请注意，板信息结构仍将显示完整的RAM数量。
如果为pRAM预留，将自动定义一个新的环境变量“mem”，以保留剩余RAM的数量，可以将其作为引导参数传递给Linux，例如：
setenv bootargs ... mem=\${mem}
saveenv
这样，您可以告诉Linux不使用此内存，这将导致一个不会受到重新启动影响的内存区域。
*警告* 如果您的板配置使用自动检测RAM大小的功能，则必须确保此内存测试不会损坏。到目前为止，已知以下板配置是“pRAM-clean”：
IVMS8, IVML24, SPD8xx,
HERMES, IP860, RPXlite, LWMON,
FLAGADM
上述文本是关于U-Boot编译选项的解释，主要涉及受保护的RAM（Protected RAM）和CONFIG_PRAM变量的功能和使用。简单翻译如下：
受保护的RAM：
U-Boot将一部分RAM设置为“受保护的”，即这部分RAM不会被U-Boot覆盖或改变。通过定义CONFIG_PRAM变量和环境变量pram，可以设置预留的受保护RAM的大小。
这部分预留的RAM在板信息结构中仍然会显示，但不会被U-Boot覆盖。如果预留了受保护的RAM，将会自动定义一个新的环境变量mem，以显示剩余的非受保护RAM的大小。
这个剩余的RAM可以作为引导参数传递给Linux等操作系统，这样操作系统就知道这部分RAM不会被U-Boot覆盖，可以安全地使用。需要注意的是，如果使用自动检测RAM大小的功能，
需要确保这个内存测试不会损坏任何数据。
到目前为止，已知一些板配置是“干净的受保护RAM”，这意味着这些配置的受保护RAM设置不会影响其他功能：
IVMS8, IVML24, SPD8xx, HERMES, IP860, RPXlite, LWMON, FLAGADM
- Error Recovery:
Note:
In the current implementation, the local variables
space and global environment variables space are
separated. Local variables are those you define by
simply typing `name=value'. To access a local
variable later on, you have write `$name' or
`${name}'; to execute the contents of a variable
directly type `$name' at the command prompt.
Global environment variables are those you use
setenv/printenv to work with. To run a command stored
in such a variable, you need to use the run command,
and you must not use the '$' sign to access them.
To store commands and special characters in a
variable, please use double quotation marks
surrounding the whole text of the variable, instead
of the backslashes before semicolons and special
symbols.
错误恢复：
注意：
在当前实现中，局部变量空间和全局环境变量空间是分开的。局部变量是您通过简单地键入“name=value”来定义的。要在稍后访问局部变量，
请使用'$name'或'${name}'；要在命令提示符下直接执行变量的内容，请键入'$name'。
全局环境变量是您使用setenv/printenv来处理的。要运行存储在这种变量中的命令，您需要使用run命令，并且不能使用'$'符号来访问它们。
要在变量中存储命令和特殊字符，请使用双引号包围整个变量的文本，而不是在分号和特殊符号前使用反斜杠。
- Default Environment:
CONFIG_EXTRA_ENV_SETTINGS
Define this to contain any number of null terminated
strings (variable = value pairs) that will be part of
the default environment compiled into the boot image.
For example, place something like this in your
board's config file:
#define CONFIG_EXTRA_ENV_SETTINGS \
"myvar1=value1\0" \
"myvar2=value2\0"
Warning: This method is based on knowledge about the
internal format how the environment is stored by the
U-Boot code. This is NOT an official, exported
interface! Although it is unlikely that this format
will change soon, there is no guarantee either.
You better know what you are doing here.
Note: overly (ab)use of the default environment is
discouraged. Make sure to check other ways to preset
the environment like the "source" command or the
boot command first.
CONFIG_DELAY_ENVIRONMENT
Normally the environment is loaded when the board is
initialised so that it is available to U-Boot. This inhibits
that so that the environment is not available until
explicitly loaded later by U-Boot code. With CONFIG_OF_CONTROL
this is instead controlled by the value of
/config/load-environment.
CONFIG_STANDALONE_LOAD_ADDR
This option defines a board specific value for the
address where standalone program gets loaded, thus
overwriting the architecture dependent default
settings.
默认环境：
CONFIG_EXTRA_ENV_SETTINGS
定义这个选项以包含任意数量的以null字符终止的字符串（变量=值对），它们将成为编译到引导映像中的默认环境的一部分。
例如，在您的板子的配置文件中放置这样：
#define CONFIG_EXTRA_ENV_SETTINGS \
"myvar1=value1\0" \
"myvar2=value2\0"
警告：此方法基于对U-Boot代码存储环境的内部格式的了解。这不是官方导出的接口！尽管这种格式很可能很快不会改变，但也不能保证。
您最好知道在这里做什么。
注意：过度滥用默认环境是不鼓励的。请确保首先检查预设环境的其他方式，如“source”命令或引导命令。
CONFIG_DELAY_ENVIRONMENT
通常，在板初始化时加载环境，以便U-Boot可以使用它。这会阻止在板初始化时加载环境，直到稍后由U-Boot代码显式加载。使用CONFIG_OF_CONTROL，这由/config/load-environment的值控制。
CONFIG_STANDALONE_LOAD_ADDR
此选项为板特定值定义了独立程序加载地址，从而覆盖了与体系结构相关的默认设置。
- Automatic software updates via TFTP server
CONFIG_UPDATE_TFTP
CONFIG_UPDATE_TFTP_CNT_MAX
CONFIG_UPDATE_TFTP_MSEC_MAX
These options enable and control the auto-update feature;
for a more detailed description refer to doc/README.update.
通过TFTP服务器进行自动软件更新
这些选项启用并控制自动更新功能；
有关更详细的说明，请参阅doc/README.update。
- MTD Support (mtdparts command, UBI support)
CONFIG_MTD_UBI_WL_THRESHOLD
This parameter defines the maximum difference between the highest
erase counter value and the lowest erase counter value of eraseblocks
of UBI devices. When this threshold is exceeded, UBI starts performing
wear leveling by means of moving data from eraseblock with low erase
counter to eraseblocks with high erase counter.
The default value should be OK for SLC NAND flashes, NOR flashes and
other flashes which have eraseblock life-cycle 100000 or more.
However, in case of MLC NAND flashes which typically have eraseblock
life-cycle less than 10000, the threshold should be lessened (e.g.,
to 128 or 256, although it does not have to be power of 2).
default: 4096
CONFIG_MTD_UBI_BEB_LIMIT
This option specifies the maximum bad physical eraseblocks UBI
expects on the MTD device (per 1024 eraseblocks). If the
underlying flash does not admit of bad eraseblocks (e.g. NOR
flash), this value is ignored.
NAND datasheets often specify the minimum and maximum NVM
(Number of Valid Blocks) for the flashes' endurance lifetime.
The maximum expected bad eraseblocks per 1024 eraseblocks
then can be calculated as "1024 * (1 - MinNVB / MaxNVB)",
which gives 20 for most NANDs (MaxNVB is basically the total
count of eraseblocks on the chip).
To put it differently, if this value is 20, UBI will try to
reserve about 1.9% of physical eraseblocks for bad blocks
handling. And that will be 1.9% of eraseblocks on the entire
NAND chip, not just the MTD partition UBI attaches. This means
that if you have, say, a NAND flash chip admits maximum 40 bad
eraseblocks, and it is split on two MTD partitions of the same
size, UBI will reserve 40 eraseblocks when attaching a
partition.
default: 20
CONFIG_MTD_UBI_FASTMAP
Fastmap is a mechanism which allows attaching an UBI device
in nearly constant time. Instead of scanning the whole MTD device it
only has to locate a checkpoint (called fastmap) on the device.
The on-flash fastmap contains all information needed to attach
the device. Using fastmap makes only sense on large devices where
attaching by scanning takes long. UBI will not automatically install
a fastmap on old images, but you can set the UBI parameter
CONFIG_MTD_UBI_FASTMAP_AUTOCONVERT to 1 if you want so. Please note
that fastmap-enabled images are still usable with UBI implementations
without fastmap support. On typical flash devices the whole fastmap
fits into one PEB. UBI will reserve PEBs to hold two fastmaps.
CONFIG_MTD_UBI_FASTMAP_AUTOCONVERT
Set this parameter to enable fastmap automatically on images
without a fastmap.
default: 0
CONFIG_MTD_UBI_FM_DEBUG
Enable UBI fastmap debug
default: 0
MTD支持（mtdparts命令、UBI支持）
CONFIG_MTD_UBI_WL_THRESHOLD
此参数定义了UBI设备中eraseblock的最大擦除计数值差异。当超过此阈值时，UBI将通过将数据从低擦除计数的eraseblock移动到高擦除计数的eraseblocks来执行磨损均衡。
对于SLC NAND闪存、NOR闪存和其他擦除块生命周期为100000或更长的闪存，默认值应该是可以的。然而，对于通常具有擦除块生命周期小于10000的MLC NAND闪存，应降低阈值（例如，到128或256，尽管它不必是2的幂）。
默认值：4096
CONFIG_MTD_UBI_BEB_LIMIT
此选项指定UBI在MTD设备上期望的最大坏物理eraseblocks（每1024个eraseblocks）。如果底层闪存不允许有坏eraseblocks（例如NOR闪存），则此值被忽略。
NAND数据表通常指定闪存耐久性寿命的最小和最大NVM（有效块数）。那么，每1024个eraseblocks的最大预期坏eraseblocks可以通过“1024 *（1 - MinNVB / MaxNVB）”计算，这给大多数NAND闪存（基本上是芯片上的总eraseblocks数）提供了20。
换句话说，如果此值为20，UBI将尝试保留约1.9％的物理eraseblocks用于处理坏块。这将是NAND芯片上1.9％的eraseblocks，而不仅仅是UBI连接的MTD分区。这意味着，如果您有一个最大允许40个坏块的NAND闪存芯片，并且它被分割成两个相同大小的MTD分区，UBI在连接分区时将保留40个eraseblocks。
默认值：20
CONFIG_MTD_UBI_FASTMAP：
Fastmap是一种机制，它允许以几乎恒定的时间连接UBI设备。与扫描整个MTD设备不同，它只需要在设备上定位一个检查点（称为fastmap）。闪存上的fastmap包含连接设备所需的所有信息。在大型设备上使用fastmap才有意义，因为在这些设备上通过扫描进行连接需要很长时间。UBI不会自动在旧镜像上安装fastmap，但如果您希望如此，可以将UBI参数CONFIG_MTD_UBI_FASTMAP_AUTOCONVERT设置为1。请注意，启用fastmap的镜像仍然可以在没有fastmap支持的UBI实现中使用。在典型的闪存设备上，整个fastmap适合一个PEB。UBI将预留PEBs来容纳两个fastmaps。
CONFIG_MTD_UBI_FASTMAP_AUTOCONVERT：
设置此参数以在缺少fastmap的镜像上自动启用fastmap。
默认值：0
CONFIG_MTD_UBI_FM_DEBUG：
启用UBI fastmap调试。
默认值：0
总的来说，这些配置选项都是为了优化UBI设备在连接和运行过程中的性能和效率。
- SPL framework
CONFIG_SPL
Enable building of SPL globally.
CONFIG_SPL_PANIC_ON_RAW_IMAGE
When defined, SPL will panic() if the image it has
loaded does not have a signature.
Defining this is useful when code which loads images
in SPL cannot guarantee that absolutely all read errors
will be caught.
An example is the LPC32XX MLC NAND driver, which will
consider that a completely unreadable NAND block is bad,
and thus should be skipped silently.
CONFIG_SPL_DISPLAY_PRINT
For ARM, enable an optional function to print more information
about the running system.
CONFIG_SPL_MPC83XX_WAIT_FOR_NAND
Set this for NAND SPL on PPC mpc83xx targets, so that
start.S waits for the rest of the SPL to load before
continuing (the hardware starts execution after just
loading the first page rather than the full 4K).
CONFIG_SPL_UBI
Support for a lightweight UBI (fastmap) scanner and
loader
CONFIG_SYS_NAND_5_ADDR_CYCLE, CONFIG_SYS_NAND_PAGE_COUNT,
CONFIG_SYS_NAND_PAGE_SIZE, CONFIG_SYS_NAND_OOBSIZE,
CONFIG_SYS_NAND_BLOCK_SIZE, CONFIG_SYS_NAND_BAD_BLOCK_POS,
CONFIG_SYS_NAND_ECCPOS, CONFIG_SYS_NAND_ECCSIZE,
CONFIG_SYS_NAND_ECCBYTES
Defines the size and behavior of the NAND that SPL uses
to read U-Boot
CONFIG_SYS_NAND_U_BOOT_DST
Location in memory to load U-Boot to
CONFIG_SYS_NAND_U_BOOT_SIZE
Size of image to load
CONFIG_SYS_NAND_U_BOOT_START
Entry point in loaded image to jump to
CONFIG_SYS_NAND_HW_ECC_OOBFIRST
Define this if you need to first read the OOB and then the
data. This is used, for example, on davinci platforms.
CONFIG_SPL_RAM_DEVICE
Support for running image already present in ram, in SPL binary
CONFIG_SPL_FIT_PRINT
Printing information about a FIT image adds quite a bit of
code to SPL. So this is normally disabled in SPL. Use this
option to re-enable it. This will affect the output of the
bootm command when booting a FIT image.
SPL框架
CONFIG_SPL：全局启用SPL的构建。
CONFIG_SPL_PANIC_ON_RAW_IMAGE：如果定义了这个选项，SPL在加载的镜像没有签名时将会panic。当在SPL中加载镜像的代码不能保证完全捕获所有读取错误时，定义此选项是有用的。
例如，LPC32XX MLC NAND驱动程序会认为一个完全无法读取的NAND块是坏的，因此应该静默地跳过。
CONFIG_SPL_DISPLAY_PRINT：对于ARM，启用一个可选函数以打印更多有关运行系统的信息。
CONFIG_SPL_MPC83XX_WAIT_FOR_NAND：对于PPC mpc83xx目标，设置此选项以便start.S在其余SPL加载之前等待（硬件仅在加载第一个页面而不是整个4K后开始执行）。
CONFIG_SPL_UBI：支持轻量级UBI（快速映射）扫描器和加载器。
CONFIG_SYS_NAND_5_ADDR_CYCLE、CONFIG_SYS_NAND_PAGE_COUNT、CONFIG_SYS_NAND_PAGE_SIZE、CONFIG_SYS_NAND_OOBSIZE、CONFIG_SYS_NAND_BLOCK_SIZE、CONFIG_SYS_NAND_BAD_BLOCK_POS、CONFIG_SYS_NAND_ECCPOS、CONFIG_SYS_NAND_ECCSIZE、CONFIG_SYS_NAND_ECCBYTES：定义了SPL用于读取U-Boot的NAND的大小和行为。
CONFIG_SYS_NAND_U_BOOT_DST：将U-Boot加载到的内存位置。
CONFIG_SYS_NAND_U_BOOT_SIZE：要加载的镜像的大小。
CONFIG_SYS_NAND_U_BOOT_START：跳转到已加载镜像的入口点。
CONFIG_SYS_NAND_HW_ECC_OOBFIRST：如果您需要先读取OOB然后读取数据，请定义此选项。例如，这在davinci平台上使用。
CONFIG_SPL_RAM_DEVICE：支持在SPL二进制文件中运行已经存在于RAM中的镜像。
CONFIG_SPL_FIT_PRINT：打印关于FIT镜像的信息会给SPL增加相当多的代码。所以这个选项通常在SPL中禁用。使用此选项可以重新启用它。这将影响bootm命令在引导一个FIT镜像时的输出。
- Interrupt support (PPC):
There are common interrupt_init() and timer_interrupt()
for all PPC archs. interrupt_init() calls interrupt_init_cpu()
for CPU specific initialization. interrupt_init_cpu()
should set decrementer_count to appropriate value. If
CPU resets decrementer automatically after interrupt
(ppc4xx) it should set decrementer_count to zero.
timer_interrupt() calls timer_interrupt_cpu() for CPU
specific handling. If board has watchdog / status_led
/ other_activity_monitor it works automatically from
general timer_interrupt().
中断支持 (PPC)：
对于所有PPC体系结构，存在通用的interrupt_init()和timer_interrupt()函数。interrupt_init()调用interrupt_init_cpu()进行CPU特定的初始化。interrupt_init_cpu()
应该将decrementer_count设置为适当的值。如果CPU在中断后自动重置decrementer（如ppc4xx），则应将decrementer_count设置为零。
timer_interrupt()调用timer_interrupt_cpu()进行CPU特定的处理。如果主板具有看门狗/状态LED/其他活动监视器，则它会自动从普通timer_interrupt()中工作。
Board initialization settings:
------------------------------
During Initialization u-boot calls a number of board specific functions
to allow the preparation of board specific prerequisites, e.g. pin setup
before drivers are initialized. To enable these callbacks the
following configuration macros have to be defined. Currently this is
architecture specific, so please check arch/your_architecture/lib/board.c
typically in board_init_f() and board_init_r().
- CONFIG_BOARD_EARLY_INIT_F: Call board_early_init_f()
- CONFIG_BOARD_EARLY_INIT_R: Call board_early_init_r()
- CONFIG_BOARD_LATE_INIT: Call board_late_init()
开发板初始化设置：
------------------------------
在初始化期间，u-boot调用了一些板特定的函数，以便准备板特定的先决条件，例如在驱动程序初始化之前进行引脚设置。为了启用这些回调，必须定义以下配置宏。
目前，这是特定于体系结构的，因此请检查arch/your_architecture/lib/board.c，通常在board_init_f()和board_init_r()中。
CONFIG_BOARD_EARLY_INIT_F：调用board_early_init_f()
CONFIG_BOARD_EARLY_INIT_R：调用board_early_init_r()
CONFIG_BOARD_LATE_INIT：调用board_late_init()
Configuration Settings:
-----------------------
- MEM_SUPPORT_64BIT_DATA: Defined automatically if compiled as 64-bit.
Optionally it can be defined to support 64-bit memory commands.
如果在64位模式下编译，则自动定义。也可以定义为支持64位内存命令。
- CONFIG_SYS_LONGHELP: Defined when you want long help messages included;
undefine this when you're short of memory.
当你想要包含长帮助消息时定义；当内存不足时取消定义。
- CONFIG_SYS_HELP_CMD_WIDTH: Defined when you want to override the default
width of the commands listed in the 'help' command output.
当你想要覆盖'help'命令输出中列出的命令的默认宽度时定义。
- CONFIG_SYS_PROMPT: This is what U-Boot prints on the console to
prompt for user input.
U-Boot在控制台上打印以提示用户输入的内容。
- CONFIG_SYS_BAUDRATE_TABLE:
List of legal baudrate settings for this board.
此板卡的合法波特率设置列表
- CONFIG_SYS_MEM_RESERVE_SECURE
Only implemented for ARMv8 for now.
If defined, the size of CONFIG_SYS_MEM_RESERVE_SECURE memory
is substracted from total RAM and won't be reported to OS.
This memory can be used as secure memory. A variable
gd->arch.secure_ram is used to track the location. In systems
the RAM base is not zero, or RAM is divided into banks,
this variable needs to be recalcuated to get the address.
目前仅在ARMv8上实现。如果定义，CONFIG_SYS_MEM_RESERVE_SECURE的大小将从总RAM中减去，并且不会报告给OS。此内存可以用作安全内存。
变量gd->arch.secure_ram用于跟踪位置。在RAM基址不为零或RAM分为几个bank的情况下，需要重新计算此变量以获取地址。
- CONFIG_SYS_LOADS_BAUD_CHANGE:
Enable temporary baudrate change while serial download
在串行下载时启用临时波特率更改。
- CONFIG_SYS_SDRAM_BASE:
Physical start address of SDRAM. _Must_ be 0 here.
SDRAM的物理起始地址，这里必须为0。
- CONFIG_SYS_FLASH_BASE:
Physical start address of Flash memory.
Flash内存的物理起始地址。
- CONFIG_SYS_MONITOR_LEN:
Size of memory reserved for monitor code, used to
determine _at_compile_time_ (!) if the environment is
embedded within the U-Boot image, or in a separate
flash sector.
为监视器代码保留的内存量，用于确定在编译时（！）环境是否嵌入U-Boot映像中，还是在单独的闪存扇区中。
- CONFIG_SYS_MALLOC_LEN:
Size of DRAM reserved for malloc() use.
为malloc()使用的DRAM保留的大小。
- CONFIG_SYS_MALLOC_F_LEN
Size of the malloc() pool for use before relocation. If
this is defined, then a very simple malloc() implementation
will become available before relocation. The address is just
below the global data, and the stack is moved down to make
space.
This feature allocates regions with increasing addresses
within the region. calloc() is supported, but realloc()
is not available. free() is supported but does nothing.
The memory will be freed (or in fact just forgotten) when
U-Boot relocates itself.
在重定位之前使用的malloc()池的大小。如果定义了这个选项，那么在重定位之前就会提供一个非常简单的malloc()实现。这个地址就在全局数据的下方，
并且会将堆栈向下移动以腾出空间。这个特性为该区域分配了不断增加的地址。虽然支持calloc()，但是不支持realloc()。free()是受支持的，但是它没有任何作用。
当U-Boot进行重定位时，该内存将被释放（或者实际上只是被遗忘）。
- CONFIG_SYS_MALLOC_SIMPLE
Provides a simple and small malloc() and calloc() for those
boards which do not use the full malloc in SPL (which is
enabled with CONFIG_SYS_SPL_MALLOC).
为那些不使用SPL中的完整malloc（由CONFIG_SYS_SPL_MALLOC启用）的板卡提供简单且小的malloc()和calloc()。
- CONFIG_SYS_NONCACHED_MEMORY:
Size of non-cached memory area. This area of memory will be
typically located right below the malloc() area and mapped
uncached in the MMU. This is useful for drivers that would
otherwise require a lot of explicit cache maintenance. For
some drivers it's also impossible to properly maintain the
cache. For example if the regions that need to be flushed
are not a multiple of the cache-line size, *and* padding
cannot be allocated between the regions to align them (i.e.
if the HW requires a contiguous array of regions, and the
size of each region is not cache-aligned), then a flush of
one region may result in overwriting data that hardware has
written to another region in the same cache-line. This can
happen for example in network drivers where descriptors for
buffers are typically smaller than the CPU cache-line (e.g.
16 bytes vs. 32 or 64 bytes).
Non-cached memory is only supported on 32-bit ARM at present.
非缓存内存的大小。这个内存区域通常位于malloc()区域下方，并在MMU中映射为未缓存。这对于需要大量显式缓存维护的驱动程序来说非常有用。
对于某些驱动程序来说，正确维护缓存是不可能的。例如，如果需要刷新的区域不是缓存行大小的倍数，并且在区域之间不能分配填充来对齐它们
（即，如果硬件需要连续的区域数组，并且每个区域的大小不是缓存对齐的），那么刷新一个区域可能会导致覆盖硬件写入同一缓存行中另一个区域的数据。
这种情况可能会出现在网络驱动程序中，其中缓冲区的描述通常比CPU缓存行小（例如，16字节与32或64字节）。
非缓存内存目前仅支持32位ARM。
- CONFIG_SYS_BOOTMAPSZ:
Maximum size of memory mapped by the startup code of
the Linux kernel; all data that must be processed by
the Linux kernel (bd_info, boot arguments, FDT blob if
used) must be put below this limit, unless "bootm_low"
environment variable is defined and non-zero. In such case
all data for the Linux kernel must be between "bootm_low"
and "bootm_low" + CONFIG_SYS_BOOTMAPSZ. The environment
variable "bootm_mapsize" will override the value of
CONFIG_SYS_BOOTMAPSZ. If CONFIG_SYS_BOOTMAPSZ is undefined,
then the value in "bootm_size" will be used instead.
Linux内核启动代码映射的最大内存大小；所有必须由Linux内核处理的数据（bd_info、启动参数、如果使用的FDTblob）必须放在这个限制之下，除非“bootm_low”
环境变量被定义并且不为零。在这种情况下，所有为Linux内核的数据必须在“bootm_low”和“bootm_low”+ CONFIG_SYS_BOOTMAPSZ之间。环境变量“bootm_mapsize”将
覆盖CONFIG_SYS_BOOTMAPSZ的值。如果未定义CONFIG_SYS_BOOTMAPSZ，那么将使用“bootm_size”中的值。
- CONFIG_SYS_BOOT_GET_CMDLINE:
Enables allocating and saving kernel cmdline in space between
"bootm_low" and "bootm_low" + BOOTMAPSZ.
启用在“bootm_low”和“bootm_low”+ BOOTMAPSZ之间分配和保存内核命令行空间。
- CONFIG_SYS_BOOT_GET_KBD:
Enables allocating and saving a kernel copy of the bd_info in
space between "bootm_low" and "bootm_low" + BOOTMAPSZ.
启用在“bootm_low”和“bootm_low”+ BOOTMAPSZ之间分配和保存内核的bd_info副本。
- CONFIG_SYS_FLASH_PROTECTION
If defined, hardware flash sectors protection is used
instead of U-Boot software protection.
如果已定义，使用硬件闪存扇区保护代替U-Boot软件保护。
- CONFIG_SYS_FLASH_CFI:
Define if the flash driver uses extra elements in the
common flash structure for storing flash geometry.
定义如果闪存驱动程序在公共闪存结构中使用额外元素来存储闪存几何形状。
- CONFIG_FLASH_CFI_DRIVER
This option also enables the building of the cfi_flash driver
in the drivers directory
此选项还启用在驱动程序目录中构建cfi_flash驱动程序。
- CONFIG_FLASH_CFI_MTD
This option enables the building of the cfi_mtd driver
in the drivers directory. The driver exports CFI flash
to the MTD layer.
此选项启用在驱动程序目录中构建cfi_mtd驱动程序。该驱动程序将CFI闪存导出到MTD层。
- CONFIG_SYS_FLASH_USE_BUFFER_WRITE
Use buffered writes to flash.
对闪存使用缓冲写入。
- CONFIG_FLASH_SPANSION_S29WS_N
s29ws-n MirrorBit flash has non-standard addresses for buffered
write commands.
s29ws-n MirrorBit flash具有非标准地址用于缓冲写入命令。
- CONFIG_FLASH_SHOW_PROGRESS
If defined (must be an integer), print out countdown
digits and dots. Recommended value: 45 (9..1) for 80
column displays, 15 (3..1) for 40 column displays.
如果定义了（必须是一个整数），打印倒计时数字和点。推荐值：45（9..1）用于80列显示，15（3..1）用于40列显示。
- CONFIG_FLASH_VERIFY
If defined, the content of the flash (destination) is compared
against the source after the write operation. An error message
will be printed when the contents are not identical.
Please note that this option is useless in nearly all cases,
since such flash programming errors usually are detected earlier
while unprotecting/erasing/programming. Please only enable
this option if you really know what you are doing.
如果定义了，在写入操作之后会比较闪存（目标）的内容与源。当内容不相同时，将打印错误消息。请注意，此选项在几乎所有情况下都是无用的，
因为这样的闪存编程错误通常在解除保护/擦除/编程时被检测到。请仅在您真正知道您在做什么的情况下启用此选项。
- CONFIG_ENV_FLAGS_LIST_DEFAULT
- CONFIG_ENV_FLAGS_LIST_STATIC
Enable validation of the values given to environment variables when
calling env set. Variables can be restricted to only decimal,
hexadecimal, or boolean. If CONFIG_CMD_NET is also defined,
the variables can also be restricted to IP address or MAC address.
启用在调用env set时对环境变量值的验证。变量可以被限制为仅十进制、十六进制或布尔值。如果同时定义了CONFIG_CMD_NET，变量也可以被限制为IP地址或MAC地址。
The format of the list is:
type_attribute = [s|d|x|b|i|m]
access_attribute = [a|r|o|c]
attributes = type_attribute[access_attribute]
entry = variable_name[:attributes]
list = entry[,list]
The type attributes are:
s - String (default)
d - Decimal
x - Hexadecimal
b - Boolean ([1yYtT|0nNfF])
i - IP address
m - MAC address
The access attributes are:
a - Any (default)
r - Read-only
o - Write-once
c - Change-default
- CONFIG_ENV_FLAGS_LIST_DEFAULT
Define this to a list (string) to define the ".flags"
environment variable in the default or embedded environment.
将其定义为字符串列表，以在默认或嵌入式环境中定义“.flags”环境变量。
- CONFIG_ENV_FLAGS_LIST_STATIC
Define this to a list (string) to define validation that
should be done if an entry is not found in the ".flags"
environment variable. To override a setting in the static
list, simply add an entry for the same variable name to the
".flags" variable.
将其定义为字符串列表，以定义如果未在“.flags”环境变量中找到条目时的验证。要覆盖静态列表中的设置，只需为相同的变量名添加一个条目到“.flags”变量中。
If CONFIG_REGEX is defined, the variable_name above is evaluated as a
regular expression. This allows multiple variables to define the same
flags without explicitly listing them for each variable.
如果定义了CONFIG_REGEX，上述的variable_name将被评估为正则表达式。这允许多个变量定义相同的标志，而不必为每个变量显式列出它们。
The following definitions that deal with the placement and management
of environment data (variable area); in general, we support the
following configurations:
以下是处理环境数据放置和管理的定义；一般来说，我们支持以下配置：
- CONFIG_BUILD_ENVCRC:
Builds up envcrc with the target environment so that external utils
may easily extract it and embed it in final U-Boot images.
BE CAREFUL! The first access to the environment happens quite early
in U-Boot initialization (when we try to get the setting of for the
console baudrate). You *MUST* have mapped your NVRAM area then, or
U-Boot will hang.
Please note that even with NVRAM we still use a copy of the
environment in RAM: we could work on NVRAM directly, but we want to
keep settings there always unmodified except somebody uses "saveenv"
to save the current settings.
BE CAREFUL! For some special cases, the local device can not use
"saveenv" command. For example, the local device will get the
environment stored in a remote NOR flash by SRIO or PCIE link,
but it can not erase, write this NOR flash by SRIO or PCIE interface.
构建envcrc与目标环境，以便外部实用程序可以轻松地提取并将其嵌入到U-Boot映像中。
注意：第一次访问环境发生在U-Boot初始化较早的阶段（当我们尝试获取控制台波特率设置时）。您必须在那时映射您的NVRAM区域，否则U-Boot将挂起。
请注意，即使使用NVRAM，我们仍然在RAM中使用环境副本：我们可以直接在NVRAM上工作，但我们希望通过“saveenv”将当前设置保存为始终不变的状态。
注意：对于某些特殊情况，本地设备不能使用“saveenv”命令。例如，本地设备将通过SRIO或PCIE链路从远程NOR flash获取环境，但它不能擦除或通过SRIO或PCIE接口写入这个NOR flash。
- CONFIG_NAND_ENV_DST
Defines address in RAM to which the nand_spl code should copy the
environment. If redundant environment is used, it will be copied to
CONFIG_NAND_ENV_DST + CONFIG_ENV_SIZE.
Please note that the environment is read-only until the monitor
has been relocated to RAM and a RAM copy of the environment has been
created; also, when using EEPROM you will have to use env_get_f()
until then to read environment variables.
The environment is protected by a CRC32 checksum. Before the monitor
is relocated into RAM, as a result of a bad CRC you will be working
with the compiled-in default environment - *silently*!!! [This is
necessary, because the first environment variable we need is the
"baudrate" setting for the console - if we have a bad CRC, we don't
have any device yet where we could complain.]
Note: once the monitor has been relocated, then it will complain if
the default environment is used; a new CRC is computed as soon as you
use the "saveenv" command to store a valid environment.
定义nand_spl代码应该复制环境的RAM地址。如果使用冗余环境，则将其复制到 CONFIG_NAND_ENV_DST + CONFIG_ENV_SIZE。
请注意，在监视器被重新定位到RAM并创建RAM环境副本之前，环境是只读的；同时，当使用EEPROM时，您需要使用env_get_f()来读取环境变量。
环境由CRC32校验和保护。在监视器被重新定位到RAM之前，由于CRC错误，您将使用编译时默认环境-悄然地！[这是必要的，因为我们需要的第一个环境变量是控制台的“波特率”设置-如果我们有错误的CRC，我们还没有任何可以提醒的设备。]
注意：一旦监视程序被重新定位，如果使用默认环境，它将会提醒；一旦你使用 "saveenv" 命令存储有效环境，新的 CRC 就会立即计算出来。
- CONFIG_SYS_FAULT_MII_ADDR:
MII address of the PHY to check for the Ethernet link state.
MII地址的PHY检查以太网链路状态。
- CONFIG_NS16550_MIN_FUNCTIONS:
Define this if you desire to only have use of the NS16550_init
and NS16550_putc functions for the serial driver located at
drivers/serial/ns16550.c. This option is useful for saving
space for already greatly restricted images, including but not
limited to NAND_SPL configurations.
如果您只想使用位于drivers/serial/ns16550.c的串行驱动程序的NS16550_init和NS16550_putc函数，请定义此选项。这个选项对于节省空间非常有用，包括但不限于NAND_SPL配置。
- CONFIG_DISPLAY_BOARDINFO
Display information about the board that U-Boot is running on
when U-Boot starts up. The board function checkboard() is called
to do this.
当U-Boot启动时，显示关于U-Boot正在运行的主板的信息。调用名为checkboard()的板函数来执行此操作。
- CONFIG_DISPLAY_BOARDINFO_LATE
Similar to the previous option, but display this information
later, once stdio is running and output goes to the LCD, if
present.
类似于前一个选项，但稍后显示此信息，一旦stdio运行并将输出发送到LCD（如果存在）。
Low Level (hardware related) configuration options:
---------------------------------------------------
- CONFIG_SYS_CACHELINE_SIZE:
Cache Line Size of the CPU.
CPU的缓存行大小。
- CONFIG_SYS_CCSRBAR_DEFAULT:
Default (power-on reset) physical address of CCSR on Freescale
PowerPC SOCs.
Freescale PowerPC SOCs上CCSR的默认（上电复位）物理地址。
- CONFIG_SYS_CCSRBAR:
Virtual address of CCSR. On a 32-bit build, this is typically
the same value as CONFIG_SYS_CCSRBAR_DEFAULT.
CCSR的虚拟地址。在32位构建中，这通常与CONFIG_SYS_CCSRBAR_DEFAULT值相同。
- CONFIG_SYS_CCSRBAR_PHYS:
Physical address of CCSR. CCSR can be relocated to a new
physical address, if desired. In this case, this macro should
be set to that address. Otherwise, it should be set to the
same value as CONFIG_SYS_CCSRBAR_DEFAULT. For example, CCSR
is typically relocated on 36-bit builds. It is recommended
that this macro be defined via the _HIGH and _LOW macros:
CCSR的物理地址。如果需要，可以重新定位CCSR到新的物理地址。在这种情况下，应将此宏设置为该地址。
否则，它应设置为与CONFIG_SYS_CCSRBAR_DEFAULT相同的值。例如，CCSR通常在36位构建中重新定位。建议通过_HIGH和_LOW宏定义此宏：
#define CONFIG_SYS_CCSRBAR_PHYS ((CONFIG_SYS_CCSRBAR_PHYS_HIGH
* 1ull) << 32 | CONFIG_SYS_CCSRBAR_PHYS_LOW)
- CONFIG_SYS_CCSRBAR_PHYS_HIGH:
Bits 33-36 of CONFIG_SYS_CCSRBAR_PHYS. This value is typically
either 0 (32-bit build) or 0xF (36-bit build). This macro is
used in assembly code, so it must not contain typecasts or
integer size suffixes (e.g. "ULL").
CONFIG_SYS_CCSRBAR_PHYS的33-36位。这个值通常要么是0（32位构建），要么是0xF（36位构建）。这个宏在汇编代码中使用，所以它不能包含类型转换或整数大小后缀（例如“ULL”）。
- CONFIG_SYS_CCSRBAR_PHYS_LOW:
Lower 32-bits of CONFIG_SYS_CCSRBAR_PHYS. This macro is
used in assembly code, so it must not contain typecasts or
integer size suffixes (e.g. "ULL").
CONFIG_SYS_CCSRBAR_PHYS的较低32位。这个宏在汇编代码中使用，所以它不能包含类型转换或整数大小后缀（例如“ULL”）。
- CONFIG_SYS_IMMR: Physical address of the Internal Memory.
DO NOT CHANGE unless you know exactly what you're
doing! (11-4) [MPC8xx systems only]
内部存储器的物理地址。除非您确切知道自己在做什么，否则请不要更改！（11-4）仅适用于MPC8xx系统
- CONFIG_SYS_INIT_RAM_ADDR:
Start address of memory area that can be used for
initial data and stack; please note that this must be
writable memory that is working WITHOUT special
initialization, i. e. you CANNOT use normal RAM which
will become available only after programming the
memory controller and running certain initialization
sequences.
U-Boot uses the following memory types:
- MPC8xx: IMMR (internal memory of the CPU)
可被用于初始数据和堆栈的内存区域的起始地址；请注意，这必须是可写入的、无需特殊初始化的工作内存，即您不能使用只有在编程内存控制器并运行某些初始化序列后才能使用的普通RAM。
U-Boot使用的内存类型如下：
- MPC8xx：IMMR（CPU的内部存储器）
- CONFIG_SYS_SCCR: System Clock and reset Control Register (15-27)
- CONFIG_SYS_OR_TIMING_SDRAM:
SDRAM timing
SDRAM时序
- CONFIG_SYS_MAMR_PTA:
periodic timer for refresh
刷新用周期计时器
- CONFIG_SYS_SRIO:
Chip has SRIO or not
芯片是否具有SRIO
- CONFIG_SRIO1:
Board has SRIO 1 port available
主板是否具有SRIO 1端口可用
- CONFIG_SRIO2:
Board has SRIO 2 port available
主板是否具有SRIO 2端口可用
- CONFIG_SRIO_PCIE_BOOT_MASTER
Board can support master function for Boot from SRIO and PCIE
主板是否能支持从SRIO和PCIE启动的主机功能
- CONFIG_SYS_SRIOn_MEM_VIRT:
Virtual Address of SRIO port 'n' memory region
SRIO端口'n'内存区域的虚拟地址
- CONFIG_SYS_SRIOn_MEM_PHYxS:
Physical Address of SRIO port 'n' memory region
SRIO端口'n'内存区域的实际地址
- CONFIG_SYS_SRIOn_MEM_SIZE:
Size of SRIO port 'n' memory region
SRIO端口'n'内存区域的大小
- CONFIG_SYS_NAND_BUSWIDTH_16BIT
Defined to tell the NAND controller that the NAND chip is using
a 16 bit bus.
Not all NAND drivers use this symbol.
Example of drivers that use it:
- drivers/mtd/nand/raw/ndfc.c
- drivers/mtd/nand/raw/mxc_nand.c
定义该符号是为了告诉NAND控制器NAND芯片正在使用16位总线。并非所有的NAND驱动程序都使用这个符号。使用该符号的驱动程序的示例包括：
- drivers/mtd/nand/raw/ndfc.c
- drivers/mtd/nand/raw/mxc_nand.c
- CONFIG_SYS_NDFC_EBC0_CFG
Sets the EBC0_CFG register for the NDFC. If not defined
a default value will be used.
为NDFC设置EBC0_CFG寄存器。如果未定义，将使用默认值。
- CONFIG_SPD_EEPROM
Get DDR timing information from an I2C EEPROM. Common
with pluggable memory modules such as SODIMMs
从I2C EEPROM获取DDR时序信息。常见于可插拔内存模块，如SODIMMs等。
SPD_EEPROM_ADDRESS
I2C address of the SPD EEPROM
- CONFIG_SYS_SPD_BUS_NUM
If SPD EEPROM is on an I2C bus other than the first
one, specify here. Note that the value must resolve
to something your driver can deal with.
如果SPD EEPROM位于除第一个之外的其他I2C总线上，请在此处指定。请注意，该值必须解析为您的驱动程序可以处理的地址。
- CONFIG_FSL_DDR_INTERACTIVE
Enable interactive DDR debugging. See doc/README.fsl-ddr.
启用交互式DDR调试。请参阅doc/README.fsl-ddr文件。
- CONFIG_FSL_DDR_SYNC_REFRESH
Enable sync of refresh for multiple controllers.
为多个控制器启用同步刷新。
- CONFIG_FSL_DDR_BIST
Enable built-in memory test for Freescale DDR controllers.
为Freescale DDR控制器启用内置内存测试。
- CONFIG_RMII
Enable RMII mode for all FECs.
Note that this is a global option, we can't
have one FEC in standard MII mode and another in RMII mode.
为所有FECs启用RMII模式。请注意，这是一个全局选项，我们不能将一个FEC设置为标准MII模式，而将另一个FEC设置为RMII模式。
- CONFIG_CRC32_VERIFY
Add a verify option to the crc32 command.
The syntax is:
=> crc32 -v <address> <count> <crc32>
Where address/count indicate a memory area
and crc32 is the correct crc32 which the
area should have.
向crc32命令添加验证选项。语法如下：
=> crc32 -v <address> <count> <crc32>
其中，address/count指示内存区域，crc32是该区域应有的正确crc32。
- CONFIG_LOOPW
Add the "loopw" memory command. This only takes effect if
the memory commands are activated globally (CONFIG_CMD_MEMORY).
添加“loopw”内存命令。如果全局启用了内存命令（CONFIG_CMD_MEMORY），此命令才会生效。
- CONFIG_CMD_MX_CYCLIC
Add the "mdc" and "mwc" memory commands. These are cyclic
"md/mw" commands.
Examples:
=> mdc.b 10 4 500
This command will print 4 bytes (10,11,12,13) each 500 ms.
=> mwc.l 100 12345678 10
This command will write 12345678 to address 100 all 10 ms.
This only takes effect if the memory commands are activated
globally (CONFIG_CMD_MEMORY).
添加“mdc”和“mwc”内存命令。这些是循环的“md/mw”命令。示例如下：
=> mdc.b 10 4 500
此命令将每500毫秒打印4个字节（10,11,12,13）。
=> mwc.l 100 12345678 10
此命令将每10毫秒向地址100写入12345678。只有当全局启用了内存命令（CONFIG_CMD_MEMORY）时，此命令才会生效。
- CONFIG_SPL_BUILD
Set when the currently-running compilation is for an artifact
that will end up in the SPL (as opposed to the TPL or U-Boot
proper). Code that needs stage-specific behavior should check
this.
在当前编译用于最终将进入SPL（相对于TPL或U-Boot本身）的工件时进行设置。需要特定阶段行为的代码应检查此选项。
- CONFIG_TPL_BUILD
Set when the currently-running compilation is for an artifact
that will end up in the TPL (as opposed to the SPL or U-Boot
proper). Code that needs stage-specific behavior should check
this.
在当前编译用于最终将进入TPL（相对于SPL或U-Boot本身）的工件时进行设置。需要特定阶段行为的代码应检查此选项。
- CONFIG_ARCH_MAP_SYSMEM
Generally U-Boot (and in particular the md command) uses
effective address. It is therefore not necessary to regard
U-Boot address as virtual addresses that need to be translated
to physical addresses. However, sandbox requires this, since
it maintains its own little RAM buffer which contains all
addressable memory. This option causes some memory accesses
to be mapped through map_sysmem() / unmap_sysmem().
通常，U-Boot（特别是md命令）使用有效地址。因此，不必将U-Boot地址视为需要翻译为物理地址的虚拟地址。然而，sandbox需要这样做，因为它维护了自己的小RAM缓冲区，
其中包含所有可寻址的内存。此选项会导致一些内存访问通过map_sysmem() / unmap_sysmem()映射。
- CONFIG_X86_RESET_VECTOR
If defined, the x86 reset vector code is included. This is not
needed when U-Boot is running from Coreboot.
如果已定义，将包含x86重置向量代码。当U-Boot从Coreboot运行时，不需要此代码。
- CONFIG_SYS_NAND_NO_SUBPAGE_WRITE
Option to disable subpage write in NAND driver
driver that uses this:
drivers/mtd/nand/raw/davinci_nand.c
禁用NAND驱动程序中使用此驱动程序的子页写入的选项：
drivers/mtd/nand/raw/davinci_nand.c
Freescale QE/FMAN Firmware Support:
-----------------------------------
The Freescale QUICCEngine (QE) and Frame Manager (FMAN) both support the
loading of "firmware", which is encoded in the QE firmware binary format.
This firmware often needs to be loaded during U-Boot booting, so macros
are used to identify the storage device (NOR flash, SPI, etc) and the address
within that device.
Freescale QUICCEngine (QE) 和 Frame Manager (FMAN) 都支持加载“固件”，这种固件以 QE 固件二进制格式进行编码。
这种固件通常需要在 U-Boot 启动过程中加载，因此使用宏来识别存储设备（NOR flash、SPI 等）和设备内的地址。
- CONFIG_SYS_FMAN_FW_ADDR
The address in the storage device where the FMAN microcode is located. The
meaning of this address depends on which CONFIG_SYS_QE_FMAN_FW_IN_xxx macro
is also specified.
这是存储设备中 FMAN 微代码的地址。该地址的含义取决于同时指定的 CONFIG_SYS_QE_FMAN_FW_IN_xxx 宏。
- CONFIG_SYS_QE_FW_ADDR
The address in the storage device where the QE microcode is located. The
meaning of this address depends on which CONFIG_SYS_QE_FMAN_FW_IN_xxx macro
is also specified.
这是存储设备中 QE 微代码的地址。该地址的含义取决于同时指定的 CONFIG_SYS_QE_FMAN_FW_IN_xxx 宏。
- CONFIG_SYS_QE_FMAN_FW_LENGTH
The maximum possible size of the firmware. The firmware binary format
has a field that specifies the actual size of the firmware, but it
might not be possible to read any part of the firmware unless some
local storage is allocated to hold the entire firmware first.
这是固件的最大可能大小。固件二进制格式有一个字段，用于指定固件的实际大小，但在将整个固件存储到本地之前，可能无法读取任何部分。
- CONFIG_SYS_QE_FMAN_FW_IN_NOR
Specifies that QE/FMAN firmware is located in NOR flash, mapped as
normal addressable memory via the LBC. CONFIG_SYS_FMAN_FW_ADDR is the
virtual address in NOR flash.
指定 QE/FMAN 固件位于 NOR flash 中，通过 LBC 作为普通可寻址内存映射。CONFIG_SYS_FMAN_FW_ADDR 是 NOR flash 中的虚拟地址
- CONFIG_SYS_QE_FMAN_FW_IN_NAND
Specifies that QE/FMAN firmware is located in NAND flash.
CONFIG_SYS_FMAN_FW_ADDR is the offset within NAND flash.
指定 QE/FMAN 固件位于 NAND flash 中。CONFIG_SYS_FMAN_FW_ADDR 是 NAND flash 中的偏移量。
- CONFIG_SYS_QE_FMAN_FW_IN_MMC
Specifies that QE/FMAN firmware is located on the primary SD/MMC
device. CONFIG_SYS_FMAN_FW_ADDR is the byte offset on that device.
指定 QE/FMAN 固件位于主 SD/MMC 设备上。CONFIG_SYS_FMAN_FW_ADDR 是该设备上的字节偏移量。
- CONFIG_SYS_QE_FMAN_FW_IN_REMOTE
Specifies that QE/FMAN firmware is located in the remote (master)
memory space. CONFIG_SYS_FMAN_FW_ADDR is a virtual address which
can be mapped from slave TLB->slave LAW->slave SRIO or PCIE outbound
window->master inbound window->master LAW->the ucode address in
master's memory space.
指定 QE/FMAN 固件位于远程（主）内存空间中。CONFIG_SYS_FMAN_FW_ADDR 是一个虚拟地址，
可以通过从TLB->slave ,LAW->slave , SRIO 或 PCIE 出窗到主设备 window->master 入窗到主设备 window->master LAW->the 的内存空间中的微代码地址进行映射。
Freescale Layerscape Management Complex Firmware Support:
---------------------------------------------------------
The Freescale Layerscape Management Complex (MC) supports the loading of
"firmware".
This firmware often needs to be loaded during U-Boot booting, so macros
are used to identify the storage device (NOR flash, SPI, etc) and the address
within that device.
- CONFIG_FSL_MC_ENET
Enable the MC driver for Layerscape SoCs.
管理复杂固件支持：
Freescale Layerscape Management Complex (MC) 支持加载 “固件”。
这种固件通常需要在 U-Boot 启动过程中加载，因此使用宏来识别存储设备（NOR flash、SPI 等）和设备内的地址。
CONFIG_FSL_MC_ENET
为 Layerscape SoCs 启用 MC 驱动。
Freescale Layerscape Debug Server Support:
-------------------------------------------
The Freescale Layerscape Debug Server Support supports the loading of
"Debug Server firmware" and triggering SP boot-rom.
This firmware often needs to be loaded during U-Boot booting.
- CONFIG_SYS_MC_RSV_MEM_ALIGN
Define alignment of reserved memory MC requires
Freescale Layerscape Debug Server 支持：
Freescale Layerscape Debug Server 支持加载 “Debug Server固件” 和触发 SP boot-rom。
这种固件通常需要在 U-Boot 启动过程中加载。
CONFIG_SYS_MC_RSV_MEM_ALIGN
定义被保留的内存对齐
Reproducible builds
-------------------
In order to achieve reproducible builds, timestamps used in the U-Boot build
process have to be set to a fixed value.
This is done using the SOURCE_DATE_EPOCH environment variable.
SOURCE_DATE_EPOCH is to be set on the build host's shell, not as a configuration
option for U-Boot or an environment variable in U-Boot.
SOURCE_DATE_EPOCH should be set to a number of seconds since the epoch, in UTC.
可重复构建
为了实现可重复构建，U-Boot 构建过程中使用的时间戳必须设置为固定值。
这是通过 SOURCE_DATE_EPOCH 环境变量完成的。SOURCE_DATE_EPOCH 应在构建主机的 shell 上设置，而不是作为 U-Boot 的配置选项或 U-Boot 内的环境变量。
SOURCE_DATE_EPOCH 应设置为自 epoch（1970年1月1日）以来的秒数，以 UTC（协调世界时）为准。
Building the Software:
======================
Building U-Boot has been tested in several native build environments
and in many different cross environments. Of course we cannot support
all possibly existing versions of cross development tools in all
(potentially obsolete) versions. In case of tool chain problems we
recommend to use the ELDK (see https://www.denx.de/wiki/DULG/ELDK)
which is extensively used to build and test U-Boot.
If you are not using a native environment, it is assumed that you
have GNU cross compiling tools available in your path. In this case,
you must set the environment variable CROSS_COMPILE in your shell.
Note that no changes to the Makefile or any other source files are
necessary. For example using the ELDK on a 4xx CPU, please enter:
$ CROSS_COMPILE=ppc_4xx-
$ export CROSS_COMPILE
U-Boot is intended to be simple to build. After installing the
sources you must configure U-Boot for one specific board type. This
is done by typing:
make NAME_defconfig
where "NAME_defconfig" is the name of one of the existing configu-
rations; see configs/*_defconfig for supported names.
Note: for some boards special configuration names may exist; check if
additional information is available from the board vendor; for
instance, the TQM823L systems are available without (standard)
or with LCD support. You can select such additional "features"
when choosing the configuration, i. e.
make TQM823L_defconfig
- will configure for a plain TQM823L, i. e. no LCD support
make TQM823L_LCD_defconfig
- will configure for a TQM823L with U-Boot console on LCD
etc.
Finally, type "make all", and you should get some working U-Boot
images ready for download to / installation on your system:
- "u-boot.bin" is a raw binary image
- "u-boot" is an image in ELF binary format
- "u-boot.srec" is in Motorola S-Record format
By default the build is performed locally and the objects are saved
in the source directory. One of the two methods can be used to change
this behavior and build U-Boot to some external directory:
1. Add O= to the make command line invocations:
make O=/tmp/build distclean
make O=/tmp/build NAME_defconfig
make O=/tmp/build all
2. Set environment variable KBUILD_OUTPUT to point to the desired location:
export KBUILD_OUTPUT=/tmp/build
make distclean
make NAME_defconfig
make all
最后，输入“make all”，你应该会得到一些可用于下载或安装到系统上的U-Boot镜像：
-“u-boot.bin”是原始二进制镜像
-“u-boot”是以ELF二进制格式的镜像
-“u-boot.srec”是以Motorola S-Record格式的镜像
默认情况下，构建是在本地执行的，并且对象保存在源目录中。可以使用以下两种方法之一来更改此行为并将U-Boot构建到某个外部目录：
1. 在make命令行中添加O=：
make O=/tmp/build distclean
make O=/tmp/build NAME_defconfig
make O=/tmp/build all
2.将环境变量KBUILD_OUTPUT设置为所需位置：
export KBUILD_OUTPUT=/tmp/build
make distclean
make NAME_defconfig
make all
Note that the command line "O=" setting overrides the KBUILD_OUTPUT environment
variable.
User specific CPPFLAGS, AFLAGS and CFLAGS can be passed to the compiler by
setting the according environment variables KCPPFLAGS, KAFLAGS and KCFLAGS.
For example to treat all compiler warnings as errors:
make KCFLAGS=-Werror
Please be aware that the Makefiles assume you are using GNU make, so
for instance on NetBSD you might need to use "gmake" instead of
native "make".
If the system board that you have is not listed, then you will need
to port U-Boot to your hardware platform. To do this, follow these
steps:
1. Create a new directory to hold your board specific code. Add any
files you need. In your board directory, you will need at least
the "Makefile" and a "<board>.c".
2. Create a new configuration file "include/configs/<board>.h" for
your board.
3. If you're porting U-Boot to a new CPU, then also create a new
directory to hold your CPU specific code. Add any files you need.
4. Run "make <board>_defconfig" with your new name.
5. Type "make", and you should get a working "u-boot.srec" file
to be installed on your target system.
6. Debug and solve any problems that might arise.
[Of course, this last step is much harder than it sounds.]
请注意，“O=”命令行设置会覆盖KBUILD_OUTPUT环境变量。
用户特定的CPPFLAGS、AFLAGS和CFLAGS可以通过设置相应的环境变量KCPPFLAGS、KAFLAGS和KCFLAGS传递给编译器。例如，将所有编译器警告视为错误：
make KCFLAGS=-Werror
请注意，Makefile假定您正在使用GNU make，因此在NetBSD上，您可能需要使用“gmake”而不是本机“make”。
如果列出的系统板不在列表中，则需要将U-Boot移植到您的硬件平台上。要执行此操作，请按照以下步骤操作：
1. 创建一个新目录来保存您的主板特定代码。添加您需要的任何文件。在您的board目录中，您将需要至少一个“Makefile”和一个“<board>.c”。
2. 为您的主板创建新的配置文件“include/configs/<board>.h”。
3. 如果您正在将U-Boot移植到新的CPU上，则还需要创建一个新目录来保存您的CPU特定代码。添加您需要的任何文件。
4. 运行“make <board>_defconfig”使用您的新名称。
5. 键入“make”，您应该得到一个可工作的“u-boot.srec”文件，以安装在目标系统上。
6. 调试并解决可能出现的任何问题。当然，这最后一步比听起来要困难得多。
Testing of U-Boot Modifications, Ports to New Hardware, etc.:
==============================================================
If you have modified U-Boot sources (for instance added a new board
or support for new devices, a new CPU, etc.) you are expected to
provide feedback to the other developers. The feedback normally takes
the form of a "patch", i.e. a context diff against a certain (latest
official or latest in the git repository) version of U-Boot sources.
But before you submit such a patch, please verify that your modifi-
cation did not break existing code. At least make sure that *ALL* of
the supported boards compile WITHOUT ANY compiler warnings. To do so,
just run the buildman script (tools/buildman/buildman), which will
configure and build U-Boot for ALL supported system. Be warned, this
will take a while. Please see the buildman README, or run 'buildman -H'
for documentation.
See also "U-Boot Porting Guide" below.
对U-Boot修改、新硬件移植等进行测试：
================================
如果你已修改U-Boot源代码（例如添加了新板卡或支持新设备、新CPU等），你应向其他开发人员提供反馈。通常，这种反馈的形式为“补丁”，
即针对特定版本（最新的官方版本或git仓库中的最新版本）的U-Boot源代码的上下文差异。
但在提交此类补丁之前，请确保你的修改没有破坏现有代码。至少要确保所有支持的板卡在没有任何编译器警告的情况下编译成功。
要完成此操作，只需运行buildman脚本（tools/buildman/buildman），该脚本将为所有支持的系统配置和构建U-Boot。请注意，这可能需要一段时间。
有关使用方法，请参阅buildman的README，或运行'buildman -H'查看文档。
Monitor Commands - Overview:
============================
go - start application at address 'addr'
run - run commands in an environment variable
bootm - boot application image from memory
bootp - boot image via network using BootP/TFTP protocol
bootz - boot zImage from memory
tftpboot- boot image via network using TFTP protocol
and env variables "ipaddr" and "serverip"
(and eventually "gatewayip")
tftpput - upload a file via network using TFTP protocol
rarpboot- boot image via network using RARP/TFTP protocol
diskboot- boot from IDE devicebootd - boot default, i.e., run 'bootcmd'
loads - load S-Record file over serial line
loadb - load binary file over serial line (kermit mode)
loadm - load binary blob from source address to destination address
md - memory display
mm - memory modify (auto-incrementing)
nm - memory modify (constant address)
mw - memory write (fill)
ms - memory search
cp - memory copy
cmp - memory compare
crc32 - checksum calculation
i2c - I2C sub-system
sspi - SPI utility commands
base - print or set address offset
printenv- print environment variables
pwm - control pwm channels
setenv - set environment variables
saveenv - save environment variables to persistent storage
protect - enable or disable FLASH write protection
erase - erase FLASH memory
flinfo - print FLASH memory information
nand - NAND memory operations (see doc/README.nand)
bdinfo - print Board Info structure
iminfo - print header information for application image
coninfo - print console devices and informations
ide - IDE sub-system
loop - infinite loop on address range
loopw - infinite write loop on address range
mtest - simple RAM test
icache - enable or disable instruction cache
dcache - enable or disable data cache
reset - Perform RESET of the CPU
echo - echo args to console
version - print monitor version
help - print online help
? - alias for 'help'
U-Boot 监视器命令 - 概述：
==============================
go - 在地址 'addr' 上启动应用程序
run - 在环境变量中运行命令
bootm - 从内存中启动应用程序镜像
bootp - 通过BootP/TFTP协议通过网络启动镜像
bootz - 从内存中启动zImage
tftpboot- 通过TFTP协议通过网络启动镜像，并使用环境变量 "ipaddr" 和 "serverip"（以及可能的 "gatewayip"）
tftpput - 通过TFTP协议通过网络上传文件
rarpboot- 通过RARP/TFTP协议通过网络启动镜像
diskboot- 从IDE设备启动
bootd - 启动默认，即运行 'bootcmd'
loads - 通过串行线路加载S-Record文件
loadb - 通过串行线路（kermit模式）加载二进制文件
loadm - 从源地址到目标地址加载二进制blob
md - 内存显示
mm - 内存修改（自动递增）
nm - 内存修改（固定地址）
mw - 内存写入（填充）
ms - 内存搜索
cp - 内存复制
cmp - 内存比较
crc32 - 计算校验和
i2c - I2C子系统
sspi - SPI实用程序命令
base - 打印或设置地址偏移量
printenv- 打印环境变量
pwm - 控制pwm通道
setenv - 设置环境变量
saveenv - 将环境变量保存到持久存储器中
protect - 启用或禁用FLASH写入保护
erase - 擦除FLASH内存
flinfo - 打印FLASH内存信息
nand - NAND内存操作（请参阅doc/README.nand）
bdinfo - 打印Board Info结构
iminfo - 打印应用程序镜像的头信息
coninfo - 打印控制台设备和信息
ide - IDE子系统
loop - 在地址范围内进行无限循环
loopw - 在地址范围内进行无限写入循环
mtest - 简单的RAM测试
icache - 启用或禁用指令缓存
dcache - 启用或禁用数据缓存
reset - 对CPU执行复位操作
echo - 将参数回显到控制台
version - 打印监视器版本号
help - 打印在线帮助
? - "help" 的别名
Monitor Commands - Detailed Description:
========================================
TODO.
For now: just type "help <command>".
监视器命令 - 详细描述：
=====================
待完成。
目前：只需键入“help <command>”。
Note for Redundant Ethernet Interfaces:
=======================================
Some boards come with redundant Ethernet interfaces; U-Boot supports
such configurations and is capable of automatic selection of a
"working" interface when needed. MAC assignment works as follows:
Network interfaces are numbered eth0, eth1, eth2, ... Corresponding
MAC addresses can be stored in the environment as "ethaddr" (=>eth0),
"eth1addr" (=>eth1), "eth2addr", ...
If the network interface stores some valid MAC address (for instance
in SROM), this is used as default address if there is NO correspon-
ding setting in the environment; if the corresponding environment
variable is set, this overrides the settings in the card; that means:
o If the SROM has a valid MAC address, and there is no address in the
environment, the SROM's address is used.
o If there is no valid address in the SROM, and a definition in the
environment exists, then the value from the environment variable is
used.
o If both the SROM and the environment contain a MAC address, and
both addresses are the same, this MAC address is used.
o If both the SROM and the environment contain a MAC address, and the
addresses differ, the value from the environment is used and a
warning is printed.
o If neither SROM nor the environment contain a MAC address, an error
is raised. If CONFIG_NET_RANDOM_ETHADDR is defined, then in this case
a random, locally-assigned MAC is used.
If Ethernet drivers implement the 'write_hwaddr' function, valid MAC addresses
will be programmed into hardware as part of the initialization process. This
may be skipped by setting the appropriate 'ethmacskip' environment variable.
The naming convention is as follows:
"ethmacskip" (=>eth0), "eth1macskip" (=>eth1) etc.
注意：冗余以太网接口：
=================
某些主板配备了冗余以太网接口；U-Boot支持这样的配置，并且能够在需要时自动选择一个“工作”接口。MAC分配工作如下：
网络接口编号为eth0、eth1、eth2，...相应的MAC地址可以存储在环境变量中为“ethaddr”（=>eth0），“eth1addr”（=>eth1），“eth2addr”，...
如果网络接口存储了一些有效的MAC地址（例如在SROM中），并且环境中没有相应的设置，那么此地址会被用作默认地址。如果环境变量中有相应的定义，这会覆盖卡中的设置；也就是说：
如果在SROM中有一个有效的MAC地址，并且环境中没有相应的地址设置，那么SROM的地址将被使用。
如果SROM中没有有效的地址，而环境中存在定义，那么环境变量中的值将被使用。
如果SROM和环境都包含相同的MAC地址，那么这个MAC地址将被使用。
如果SROM和环境包含不同的MAC地址，那么环境中的值将被使用，并打印一条警告。
如果SROM和环境都没有有效的MAC地址，那么将会引发一个错误。如果配置了CONFIG_NET_RANDOM_ETHADDR，那么在这种情况下会使用一个随机、本地分配的MAC。
如果以太网驱动实现了'write_hwaddr'函数，那么在初始化过程中，有效MAC地址将被写入硬件中。可以通过设置相应的'ethmacskip'环境变量来跳过此步骤。命名规则如下：“ethmacskip”（=>eth0）、“eth1macskip”（=>eth1）等等。
Image Formats:
==============
U-Boot is capable of booting (and performing other auxiliary operations on)
images in two formats:
New uImage format (FIT)
-----------------------
Flexible and powerful format based on Flattened Image Tree -- FIT (similar
to Flattened Device Tree). It allows the use of images with multiple
components (several kernels, ramdisks, etc.), with contents protected by
SHA1, MD5 or CRC32. More details are found in the doc/uImage.FIT directory.
Old uImage format
-----------------
Old image format is based on binary files which can be basically anything,
preceded by a special header; see the definitions in include/image.h for
details; basically, the header defines the following image properties:
* Target Operating System (Provisions for OpenBSD, NetBSD, FreeBSD,
4.4BSD, Linux, SVR4, Esix, Solaris, Irix, SCO, Dell, NCR, VxWorks,
LynxOS, pSOS, QNX, RTEMS, INTEGRITY;
Currently supported: Linux, NetBSD, VxWorks, QNX, RTEMS, INTEGRITY).
* Target CPU Architecture (Provisions for Alpha, ARM, Intel x86,
IA64, MIPS, Nios II, PowerPC, IBM S390, SuperH, Sparc, Sparc 64 Bit;
Currently supported: ARM, Intel x86, MIPS, Nios II, PowerPC).
* Compression Type (uncompressed, gzip, bzip2)
* Load Address
* Entry Point
* Image Name
* Image Timestamp
The header is marked by a special Magic Number, and both the header
and the data portions of the image are secured against corruption by
CRC32 checksums.
U-Boot支持两种格式的映像进行启动（和其它辅助操作）：
1. 新uImage格式（FIT）
这是基于Flattened Image Tree（FIT）的灵活强大的格式（类似于Flattened Device Tree）。该格式支持使用具有多个组件（多个内核，ramdisk等），其内容受SHA1、MD5或CRC32保护。更多详细信息可以在doc/uImage.FIT目录中找到。
2. 旧uImage格式
旧映像格式基于二进制文件，这些文件可以是任何东西，但前面有一个特殊的头部。这个头部定义了映像的一些属性，详细定义可以在include/image.h中找到。基本上，头部定义了以下映像属性：
* 目标操作系统（为OpenBSD、NetBSD、FreeBSD、4.4BSD、Linux、SVR4、Esix、Solaris、Irix、SCO、Dell、NCR、VxWorks、LynxOS、pSOS、QNX、RTEMS、INTEGRITY准备；目前支持：Linux、NetBSD、VxWorks、QNX、RTEMS、INTEGRITY）。
* 目标CPU架构（为Alpha、ARM、Intel x86、IA64、MIPS、Nios II、PowerPC、IBM S390、SuperH、Sparc、Sparc 64 Bit准备；目前支持：ARM、Intel x86、MIPS、Nios II、PowerPC）。
* 压缩类型（未压缩，gzip，bzip2）。
* 加载地址。
* 入口点。
* 映像名称。
* 映像时间戳。
头部由一个特殊的魔法数标记，并且头部和数据部分都通过CRC32校验和来保护免受损坏。
Linux Support:
==============
Although U-Boot should support any OS or standalone application
easily, the main focus has always been on Linux during the design of
U-Boot.
U-Boot includes many features that so far have been part of some
special "boot loader" code within the Linux kernel. Also, any
"initrd" images to be used are no longer part of one big Linux image;
instead, kernel and "initrd" are separate images. This implementation
serves several purposes:
- the same features can be used for other OS or standalone
applications (for instance: using compressed images to reduce the
Flash memory footprint)
- it becomes much easier to port new Linux kernel versions because
lots of low-level, hardware dependent stuff are done by U-Boot
- the same Linux kernel image can now be used with different "initrd"
images; of course this also means that different kernel images can
be run with the same "initrd". This makes testing easier (you don't
have to build a new "zImage.initrd" Linux image when you just
change a file in your "initrd"). Also, a field-upgrade of the
software is easier now.
Linux支持：
=========
尽管U-Boot应该很容易支持任何操作系统或独立应用程序，但在U-Boot的设计过程中，主要关注的始终是Linux。
U-Boot包含许多迄今为止已成为Linux内核中某些特殊“引导加载程序”代码一部分的功能。此外，任何要使用的“initrd”镜像不再是大的Linux镜像的一部分；相反，内核和“initrd”是单独的镜像。这种实现有几个目的：
- 相同的功能可以用于其他操作系统或独立应用程序（例如：使用压缩镜像来减少闪存占用的空间）
- 移植新的Linux内核版本变得更加容易，因为许多底层和硬件相关的东西由U-Boot来完成
- 相同的Linux内核镜像现在可以使用不同的“initrd”镜像；当然，这也意味着不同的内核镜像可以使用相同的“initrd”。
这使得测试更加容易（当您只需更改“initrd”中的文件时，您不必构建新的“zImage.initrd”Linux镜像）。此外，现在更容易进行现场软件升级。
Linux HOWTO:
============
Porting Linux to U-Boot based systems:
---------------------------------------
U-Boot cannot save you from doing all the necessary modifications to
configure the Linux device drivers for use with your target hardware
(no, we don't intend to provide a full virtual machine interface to
Linux :-).
But now you can ignore ALL boot loader code (in arch/powerpc/mbxboot).
Just make sure your machine specific header file (for instance
include/asm-ppc/tqm8xx.h) includes the same definition of the Board
Information structure as we define in include/asm-<arch>/u-boot.h,
and make sure that your definition of IMAP_ADDR uses the same value
as your U-Boot configuration in CONFIG_SYS_IMMR.
Note that U-Boot now has a driver model, a unified model for drivers.
If you are adding a new driver, plumb it into driver model. If there
is no uclass available, you are encouraged to create one. See
doc/driver-model.
Linux HOWTO：
===========
将Linux移植到基于U-Boot的系统中：
-----------------------------
U-Boot并不能帮你省去所有必要的修改，以便为你的目标硬件配置Linux设备驱动（不，我们不打算为Linux提供一个完整的虚拟机接口）。
但现在你可以忽略所有引导加载程序代码（在arch/powerpc/mbxboot中）。
只需确保你的机器特定头文件（例如include/asm-ppc/tqm8xx.h）包含了与我们在include/asm-<arch>/u-boot.h中定义的相同的板信息结构定义，
并确保你的IMAP_ADDR定义使用与你的U-Boot配置中CONFIG_SYS_IMMR相同的值。
请注意，U-Boot现在有一个驱动模型，这是一个统一的驱动模型。如果你正在添加一个新的驱动，将其整合到驱动模型中。
如果还没有可用的uclass，我们鼓励你创建一个。请查看doc/driver-model。
Configuring the Linux kernel:
-----------------------------
No specific requirements for U-Boot. Make sure you have some root
device (initial ramdisk, NFS) for your target system.
配置Linux内核：
-----------
对于U-Boot，没有特定的要求。确保为您的目标系统提供了一些根设备（初始ramdisk，NFS）。
Building a Linux Image:
构建Linux镜像：
-----------------------
With U-Boot, "normal" build targets like "zImage" or "bzImage" are
not used. If you use recent kernel source, a new build target
"uImage" will exist which automatically builds an image usable by
U-Boot. Most older kernels also have support for a "pImage" target,
which was introduced for our predecessor project PPCBoot and uses a
100% compatible format.
使用U-Boot时，不使用“普通”构建目标，如“zImage”或“bzImage”。 如果您使用的是较新的内核源代码，则将存在一个名为“uImage”的新构建目标，
该目标可以自动构建可用于U-Boot的镜像。 大多数较旧的内核还支持一个名为“pImage”的目标，该目标是在我们的前身项目PPCBoot中引入的，并使用100％兼容的格式。
Example:
make TQM850L_defconfig
make oldconfig
make dep
make uImage
The "uImage" build target uses a special tool (in 'tools/mkimage') to
encapsulate a compressed Linux kernel image with header information,
CRC32 checksum etc. for use with U-Boot. This is what we are doing:
构建“uImage”目标使用一个特殊的工具（在'tools/mkimage'中）来封装具有头信息，CRC32校验和等的压缩Linux内核镜像，以便与U-Boot一起使用。 这是我们的操作步骤：
* build a standard "vmlinux" kernel image (in ELF binary format):
* 构建一个标准“vmlinux”内核镜像（在ELF二进制格式中）：
* convert the kernel into a raw binary image:
* 将内核转换为原始二进制镜像：
${CROSS_COMPILE}-objcopy -O binary \
-R .note -R .comment \
-S vmlinux linux.bin
* compress the binary image:
* 压缩二进制镜像
gzip -9 linux.bin
* package compressed binary image for U-Boot:
* 为U-Boot打包压缩的二进制镜像：
mkimage -A ppc -O linux -T kernel -C gzip \
-a 0 -e 0 -n "Linux Kernel Image" \
-d linux.bin.gz uImage
The "mkimage" tool can also be used to create ramdisk images for use
with U-Boot, either separated from the Linux kernel image, or
combined into one file. "mkimage" encapsulates the images with a 64
byte header containing information about target architecture,
operating system, image type, compression method, entry points, time
stamp, CRC32 checksums, etc.
"mkimage" can be called in two ways: to verify existing images and
print the header information, or to build new images.
In the first form (with "-l" option) mkimage lists the information
contained in the header of an existing U-Boot image; this includes
checksum verification:
tools/mkimage -l image
-l ==> list image header information
The second form (with "-d" option) is used to build a U-Boot image
from a "data file" which is used as image payload:
tools/mkimage -A arch -O os -T type -C comp -a addr -e ep \
-n name -d data_file image
-A ==> set architecture to 'arch'
-O ==> set operating system to 'os'
-T ==> set image type to 'type'
-C ==> set compression type 'comp'
-a ==> set load address to 'addr' (hex)
-e ==> set entry point to 'ep' (hex)
-n ==> set image name to 'name'
-d ==> use image data from 'datafile'
Right now, all Linux kernels for PowerPC systems use the same load
address (0x00000000), but the entry point address depends on the
kernel version:
“mkimage”工具还可以用于创建用于U-Boot的ramdisk镜像，可以与Linux内核镜像分开使用，或合并成一个文件。“mkimage”用包含64字节头信息的封装镜像，头信息包括目标体系结构、操作系统、镜像类型、压缩方法、入口点、时间戳、CRC32校验等。
“mkimage”可以以两种方式调用：验证现有镜像并打印头信息，或构建新镜像。
第一种形式（带有“-l”选项）mkimage列出现有U-Boot镜像头中的信息，包括校验和验证：
tools/mkimage -l image
-l ==> 列出镜像头信息
第二种形式（带有“-d”选项）用于从作为镜像有效载荷的“数据文件”构建U-Boot镜像：
tools/mkimage -A arch -O os -T type -C comp -a addr -e ep
-n name -d data_file image
-A ==> 将架构设置为'arch'
-O ==> 将操作系统设置为'os'
-T ==> 将镜像类型设置为'type'
-C ==> 将压缩类型设置为'comp'
-a ==> 将加载地址设置为'addr'（十六进制）
-e ==> 将入口点设置为'ep'（十六进制）
-n ==> 将镜像名称设置为'name'
-d ==> 从'datafile'获取镜像数据
目前，所有PowerPC系统的Linux内核都使用相同的加载地址（0x00000000），但入口点地址取决于内核版本：
- 2.2.x kernels have the entry point at 0x0000000C,
- 2.3.x and later kernels have the entry point at 0x00000000.
在构建Linux镜像时，需要注意以下事项：
对于2.2.x内核，入口点位于0x0000000C，而2.3.x及以后的内核，入口点则位于0x00000000。
So a typical call to build a U-Boot image would read:
因此，典型构建U-Boot镜像的命令如下：
-> tools/mkimage -n '2.4.4 kernel for TQM850L' \
> -A ppc -O linux -T kernel -C gzip -a 0 -e 0 \
> -d /opt/elsk/ppc_8xx/usr/src/linux-2.4.4/arch/powerpc/coffboot/vmlinux.gz \
> examples/uImage.TQM850L
Image Name: 2.4.4 kernel for TQM850L
Created: Wed Jul 19 02:34:59 2000
Image Type: PowerPC Linux Kernel Image (gzip compressed)
Data Size: 335725 Bytes = 327.86 kB = 0.32 MB
Load Address: 0x00000000
Entry Point: 0x00000000
To verify the contents of the image (or check for corruption):
要验证镜像的内容或检查其是否损坏，可以使用以下命令：
-> tools/mkimage -l examples/uImage.TQM850L
Image Name: 2.4.4 kernel for TQM850L
Created: Wed Jul 19 02:34:59 2000
Image Type: PowerPC Linux Kernel Image (gzip compressed)
Data Size: 335725 Bytes = 327.86 kB = 0.32 MB
Load Address: 0x00000000
Entry Point: 0x00000000
NOTE: for embedded systems where boot time is critical you can trade
speed for memory and install an UNCOMPRESSED image instead: this
needs more space in Flash, but boots much faster since it does not
need to be uncompressed:
请注意，对于boot时间至关重要的嵌入式系统，您可以通过牺牲速度来换取内存并安装未压缩的镜像：
这会在Flash中占用更多空间，但由于不需要解压缩，因此启动速度要快得多。
-> gunzip /opt/elsk/ppc_8xx/usr/src/linux-2.4.4/arch/powerpc/coffboot/vmlinux.gz
-> tools/mkimage -n '2.4.4 kernel for TQM850L' \
> -A ppc -O linux -T kernel -C none -a 0 -e 0 \
> -d /opt/elsk/ppc_8xx/usr/src/linux-2.4.4/arch/powerpc/coffboot/vmlinux \
> examples/uImage.TQM850L-uncompressed
Image Name: 2.4.4 kernel for TQM850L
Created: Wed Jul 19 02:34:59 2000
Image Type: PowerPC Linux Kernel Image (uncompressed)
Data Size: 792160 Bytes = 773.59 kB = 0.76 MB
Load Address: 0x00000000
Entry Point: 0x00000000
Similar you can build U-Boot images from a 'ramdisk.image.gz' file
when your kernel is intended to use an initial ramdisk:
类似地，当您的内核打算使用初始ramdisk时，您可以使用'ramdisk.image.gz'文件构建U-Boot镜像：
-> tools/mkimage -n 'Simple Ramdisk Image' \
> -A ppc -O linux -T ramdisk -C gzip \
> -d /LinuxPPC/images/SIMPLE-ramdisk.image.gz examples/simple-initrd
Image Name: Simple Ramdisk Image
Created: Wed Jan 12 14:01:50 2000
Image Type: PowerPC Linux RAMDisk Image (gzip compressed)
Data Size: 566530 Bytes = 553.25 kB = 0.54 MB
Load Address: 0x00000000
Entry Point: 0x00000000
The "dumpimage" tool can be used to disassemble or list the contents of images
built by mkimage. See dumpimage's help output (-h) for details.
可以使用“dumpimage”工具来解汇编或列出由mkimage构建的镜像的内容。有关dumpimage帮助输出的详细信息，请参阅dumpimage的帮助输出（-h）。
Installing a Linux Image:
安装linux镜像
-------------------------
To downloading a U-Boot image over the serial (console) interface,
you must convert the image to S-Record format:
objcopy -I binary -O srec examples/image examples/image.srec
The 'objcopy' does not understand the information in the U-Boot
image header, so the resulting S-Record file will be relative to
address 0x00000000. To load it to a given address, you need to
specify the target address as 'offset' parameter with the 'loads'
command.
Example: install the image to address 0x40100000 (which on the
TQM8xxL is in the first Flash bank):
为了通过串行（控制台）接口下载U-Boot镜像，您需要将该镜像转换为S-Record格式：
`objcopy -I binary -O srec examples/image examples/image.srec`
'objcopy'不理解U-Boot镜像头中的信息，因此生成的S-Record文件将以地址0x00000000为基准。要将它加载到给定地址，您需要使用'loads'命令指定目标地址作为'offset'参数。
例如：将镜像安装到地址0x40100000（在TQM8xxL上，这是第一个Flash bank的地址）：
=> erase 40100000 401FFFFF
.......... done
Erased 8 sectors
=> loads 40100000
## Ready for S-Record download ...
~>examples/image.srec
1 2 3 4 5 6 7 8 9 10 11 12 13 ...
...
15989 15990 15991 15992
[file transfer complete]
[connected]
## Start Addr = 0x00000000
You can check the success of the download using the 'iminfo' command;
this includes a checksum verification so you can be sure no data
corruption happened:
您可以使用'iminfo'命令检查下载是否成功；这包括校验和验证，以确保数据没有损坏：
=> imi 40100000
## Checking Image at 40100000 ...
Image Name: 2.2.13 for initrd on TQM850L
Image Type: PowerPC Linux Kernel Image (gzip compressed)
Data Size: 335725 Bytes = 327 kB = 0 MB
Load Address: 00000000
Entry Point: 0000000c
Verifying Checksum ... OK
Boot Linux:
启动Linux：
-----------
The "bootm" command is used to boot an application that is stored in
memory (RAM or Flash). In case of a Linux kernel image, the contents
of the "bootargs" environment variable is passed to the kernel as
parameters. You can check and modify this variable using the
"printenv" and "setenv" commands:
"bootm"命令用于启动存储在内存（RAM或Flash）中的应用程序。在Linux内核映像的情况下，将"bootargs"环境变量的内容传递给内核作为参数。您可以使用"printenv"和"setenv"命令检查和修改此变量：
=> printenv bootargs
bootargs=root=/dev/ram
=> setenv bootargs root=/dev/nfs rw nfsroot=10.0.0.2:/LinuxPPC nfsaddrs=10.0.0.99:10.0.0.2
=> printenv bootargs
bootargs=root=/dev/nfs rw nfsroot=10.0.0.2:/LinuxPPC nfsaddrs=10.0.0.99:10.0.0.2
=> bootm 40020000
## Booting Linux kernel at 40020000 ...
Image Name: 2.2.13 for NFS on TQM850L
Image Type: PowerPC Linux Kernel Image (gzip compressed)
Data Size: 381681 Bytes = 372 kB = 0 MB
Load Address: 00000000
Entry Point: 0000000c
Verifying Checksum ... OK
Uncompressing Kernel Image ... OK
Linux version 2.2.13 (wd@denx.local.net) (gcc version 2.95.2 19991024 (release)) #1 Wed Jul 19 02:35:17 MEST 2000
Boot arguments: root=/dev/nfs rw nfsroot=10.0.0.2:/LinuxPPC nfsaddrs=10.0.0.99:10.0.0.2
time_init: decrementer frequency = 187500000/60
Calibrating delay loop... 49.77 BogoMIPS
Memory: 15208k available (700k kernel code, 444k data, 32k init) [c0000000,c1000000]
...
If you want to boot a Linux kernel with initial RAM disk, you pass
the memory addresses of both the kernel and the initrd image (PPBCOOT
format!) to the "bootm" command:
如果你想使用初始RAM磁盘启动Linux内核，你需要将内核和initrd映像（PPBCOOT格式！）的内存地址传递给“bootm”命令：
```
bootm <kernel_address> <initrd_address>
```
其中，`<kernel_address>`是内核在RAM中的地址，`<initrd_address>`是initrd映像在RAM中的地址。例如，如果你的内核位于RAM的0x40000000地址处，initrd映像位于RAM的0x41000000地址处，你可以使用以下命令来启动系统：
```
bootm 40000000 41000000
```
=> imi 40100000 40200000
## Checking Image at 40100000 ...
Image Name: 2.2.13 for initrd on TQM850L
Image Type: PowerPC Linux Kernel Image (gzip compressed)
Data Size: 335725 Bytes = 327 kB = 0 MB
Load Address: 00000000
Entry Point: 0000000c
Verifying Checksum ... OK
## Checking Image at 40200000 ...
Image Name: Simple Ramdisk Image
Image Type: PowerPC Linux RAMDisk Image (gzip compressed)
Data Size: 566530 Bytes = 553 kB = 0 MB
Load Address: 00000000
Entry Point: 00000000
Verifying Checksum ... OK
=> bootm 40100000 40200000
## Booting Linux kernel at 40100000 ...
Image Name: 2.2.13 for initrd on TQM850L
Image Type: PowerPC Linux Kernel Image (gzip compressed)
Data Size: 335725 Bytes = 327 kB = 0 MB
Load Address: 00000000
Entry Point: 0000000c
Verifying Checksum ... OK
Uncompressing Kernel Image ... OK
## Loading RAMDisk Image at 40200000 ...
Image Name: Simple Ramdisk Image
Image Type: PowerPC Linux RAMDisk Image (gzip compressed)
Data Size: 566530 Bytes = 553 kB = 0 MB
Load Address: 00000000
Entry Point: 00000000
Verifying Checksum ... OK
Loading Ramdisk ... OK
Linux version 2.2.13 (wd@denx.local.net) (gcc version 2.95.2 19991024 (release)) #1 Wed Jul 19 02:32:08 MEST 2000
Boot arguments: root=/dev/ram
time_init: decrementer frequency = 187500000/60
Calibrating delay loop... 49.77 BogoMIPS
...
RAMDISK: Compressed image found at block 0
VFS: Mounted root (ext2 filesystem).
bash#
Boot Linux and pass a flat device tree:
启动 Linux 并传递一个扁平的设备树：
-----------
First, U-Boot must be compiled with the appropriate defines. See the section
titled "Linux Kernel Interface" above for a more in depth explanation. The
following is an example of how to start a kernel and pass an updated
flat device tree:
首先，必须使用适当的定义编译U-Boot。请参阅上文标题为“Linux内核接口”的部分，以获取更深入的解释。以下是一个如何启动内核并传递更新的扁平设备树的示例：
=> print oftaddr
oftaddr=0x300000
=> print oft
oft=oftrees/mpc8540ads.dtb
=> tftp $oftaddr $oft
Speed: 1000, full duplex
Using TSEC0 device
TFTP from server 192.168.1.1; our IP address is 192.168.1.101
Filename 'oftrees/mpc8540ads.dtb'.
Load address: 0x300000
Loading: #
done
Bytes transferred = 4106 (100a hex)
=> tftp $loadaddr $bootfile
Speed: 1000, full duplex
Using TSEC0 device
TFTP from server 192.168.1.1; our IP address is 192.168.1.2
Filename 'uImage'.
Load address: 0x200000
Loading:############
done
Bytes transferred = 1029407 (fb51f hex)
=> print loadaddr
loadaddr=200000
=> print oftaddr
oftaddr=0x300000
=> bootm $loadaddr - $oftaddr
## Booting image at 00200000 ...
Image Name: Linux-2.6.17-dirty
Image Type: PowerPC Linux Kernel Image (gzip compressed)
Data Size: 1029343 Bytes = 1005.2 kB
Load Address: 00000000
Entry Point: 00000000
Verifying Checksum ... OK
Uncompressing Kernel Image ... OK
Booting using flat device tree at 0x300000
Using MPC85xx ADS machine description
Memory CAM mapping: CAM0=256Mb, CAM1=256Mb, CAM2=0Mb residual: 0Mb
[snip]
More About U-Boot Image Types:
更多关于U-Boot镜像类型的信息：
------------------------------
U-Boot supports the following image types:
"Standalone Programs" are directly runnable in the environment
provided by U-Boot; it is expected that (if they behave
well) you can continue to work in U-Boot after return from
the Standalone Program.
"OS Kernel Images" are usually images of some Embedded OS which
will take over control completely. Usually these programs
will install their own set of exception handlers, device
drivers, set up the MMU, etc. - this means, that you cannot
expect to re-enter U-Boot except by resetting the CPU.
"RAMDisk Images" are more or less just data blocks, and their
parameters (address, size) are passed to an OS kernel that is
being started.
"Multi-File Images" contain several images, typically an OS
(Linux) kernel image and one or more data images like
RAMDisks. This construct is useful for instance when you want
to boot over the network using BOOTP etc., where the boot
server provides just a single image file, but you want to get
for instance an OS kernel and a RAMDisk image.
"Multi-File Images" start with a list of image sizes, each
image size (in bytes) specified by an "uint32_t" in network
byte order. This list is terminated by an "(uint32_t)0".
Immediately after the terminating 0 follow the images, one by
one, all aligned on "uint32_t" boundaries (size rounded up to
a multiple of 4 bytes).
"Firmware Images" are binary images containing firmware (like
U-Boot or FPGA images) which usually will be programmed to
flash memory.
"Script files" are command sequences that will be executed by
U-Boot's command interpreter; this feature is especially
useful when you configure U-Boot to use a real shell (hush)
as command interpreter.
U-Boot支持以下镜像类型：
“独立程序”：这些程序可以直接在U-Boot的环境中运行；如果它们运行良好，你可以在从独立程序返回后继续在U-Boot中进行工作。
“操作系统内核镜像”：这些通常是某些嵌入式操作系统的镜像，这些操作系统将完全接管控制。通常，这些程序会安装自己的异常处理程序、设备驱动程序，并设置MMU等，这意味着，除了重置CPU外，你无法期望重新进入U-Boot。
“RAMDisk镜像”：这些基本上只是数据块，其参数（地址、大小）会传递给正在启动的操作系统内核。
“多文件镜像”：这些镜像包含多个镜像，通常是一个Linux内核镜像和一个或多个数据镜像（如RAMDisks）。这种构造在网络上使用BOOTP等进行引导时非常有用，其中引导服务器只提供单个镜像文件，但你想要获得一个操作系统内核和一个RAMDisk镜像。
“多文件镜像”以一个镜像大小列表开始，每个镜像大小（以字节为单位）由一个“uint32_t”指定，以网络字节顺序排列。该列表以一个终止的0结束。紧接着终止的0是镜像，一个接一个，都与“uint32_t”的边界对齐（大小向上舍入到4字节的倍数）。
“固件镜像”：这些是包含固件（如U-Boot或FPGA镜像）的二进制镜像，通常会被编程到闪存中。
“脚本文件”：这些是命令序列，将由U-Boot的命令解释器执行。当您将U-Boot配置为使用真正的shell（hush）作为命令解释器时，此功能特别有用。
Booting the Linux zImage:
引导Linux zImage：
-------------------------
On some platforms, it's possible to boot Linux zImage. This is done
using the "bootz" command. The syntax of "bootz" command is the same
as the syntax of "bootm" command.
Note, defining the CONFIG_SUPPORT_RAW_INITRD allows user to supply
kernel with raw initrd images. The syntax is slightly different, the
address of the initrd must be augmented by it's size, in the following
format: "<initrd addres>:<initrd size>".
在一些平台上，有可能引导Linux zImage。这是通过使用“bootz”命令完成的。 “bootz”命令的语法与“bootm”命令的语法相同。
注意，定义CONFIG_SUPPORT_RAW_INITRD可以让用户向内核提供原始的initrd镜像。语法略有不同，initrd的地址必须由其大小补充，以下格式：“<initrd地址>:<initrd大小>”。
Standalone HOWTO:
独立应用程序指南：
=================
One of the features of U-Boot is that you can dynamically load and
run "standalone" applications, which can use some resources of
U-Boot like console I/O functions or interrupt services.
Two simple examples are included with the sources:
U-Boot的一个特性是，您可以动态加载和运行“独立”应用程序，这些应用程序可以使用U-Boot的一些资源，如控制台I/O函数或中断服务。
源代码中包含两个简单的示例：
"Hello World" Demo:
-------------------
'examples/hello_world.c' contains a small "Hello World" Demo
application; it is automatically compiled when you build U-Boot.
It's configured to run at address 0x00040004, so you can play with it
like that:
“Hello World”演示程序：
'examples/hello_world.c'包含了一个小型“Hello World”演示应用程序；当您构建U-Boot时，它会自动编译。
它被配置为在地址0x00040004处运行，你可以像这样运行它：
=> loads
## Ready for S-Record download ...
~>examples/hello_world.srec
1 2 3 4 5 6 7 8 9 10 11 ...
[file transfer complete]
[connected]
## Start Addr = 0x00040004
=> go 40004 Hello World! This is a test.
## Starting application at 0x00040004 ...
Hello World
argc = 7
argv[0] = "40004"
argv[1] = "Hello"
argv[2] = "World!"
argv[3] = "This"
argv[4] = "is"
argv[5] = "a"
argv[6] = "test."
argv[7] = "<NULL>"
Hit any key to exit ...
## Application terminated, rc = 0x0
Another example, which demonstrates how to register a CPM interrupt
handler with the U-Boot code, can be found in 'examples/timer.c'.
Here, a CPM timer is set up to generate an interrupt every second.
The interrupt service routine is trivial, just printing a '.'
character, but this is just a demo program. The application can be
controlled by the following keys:
? - print current values og the CPM Timer registers
b - enable interrupts and start timer
e - stop timer and disable interrupts
q - quit application
另一个示例，演示如何在U-Boot代码中注册CPM中断处理程序，可以在'examples/timer.c'中找到。在这里，CPM定时器每秒钟产生一个中断。
中断服务程序很简单，只是打印一个点号字符，但这只是一个演示程序。该应用程序可以通过以下键进行控制：
? - 打印CPM定时器寄存器的当前值
b - 使能中断并启动定时器
e - 停止定时器并禁用中断
q - 退出应用程序
=> loads
## Ready for S-Record download ...
~>examples/timer.srec
1 2 3 4 5 6 7 8 9 10 11 ...
[file transfer complete]
[connected]
## Start Addr = 0x00040004
=> go 40004
## Starting application at 0x00040004 ...
TIMERS=0xfff00980
Using timer 1
tgcr @ 0xfff00980, tmr @ 0xfff00990, trr @ 0xfff00994, tcr @ 0xfff00998, tcn @ 0xfff0099c, ter @ 0xfff009b0
Hit 'b':
[q, b, e, ?] Set interval 1000000 us
Enabling timer
Hit '?':
[q, b, e, ?] ........
tgcr=0x1, tmr=0xff1c, trr=0x3d09, tcr=0x0, tcn=0xef6, ter=0x0
Hit '?':
[q, b, e, ?] .
tgcr=0x1, tmr=0xff1c, trr=0x3d09, tcr=0x0, tcn=0x2ad4, ter=0x0
Hit '?':
[q, b, e, ?] .
tgcr=0x1, tmr=0xff1c, trr=0x3d09, tcr=0x0, tcn=0x1efc, ter=0x0
Hit '?':
[q, b, e, ?] .
tgcr=0x1, tmr=0xff1c, trr=0x3d09, tcr=0x0, tcn=0x169d, ter=0x0
Hit 'e':
[q, b, e, ?] ...Stopping timer
Hit 'q':
[q, b, e, ?] ## Application terminated, rc = 0x0
Minicom warning:
================
Over time, many people have reported problems when trying to use the
"minicom" terminal emulation program for serial download. I (wd)
consider minicom to be broken, and recommend not to use it. Under
Unix, I recommend to use C-Kermit for general purpose use (and
especially for kermit binary protocol download ("loadb" command), and
use "cu" for S-Record download ("loads" command). See
https://www.denx.de/wiki/view/DULG/SystemSetup#Section_4.3.
for help with kermit.
Nevertheless, if you absolutely want to use it try adding this
configuration to your "File transfer protocols" section:
Name Program Name U/D FullScr IO-Red. Multi
X kermit /usr/bin/kermit -i -l %l -s Y U Y N N
Y kermit /usr/bin/kermit -i -l %l -r N D Y N N
Minicom警告：
随着时间的推移，许多人在尝试使用“minicom”终端仿真程序进行串行下载时遇到了问题。我（wd）认为minicom已经损坏，建议不要使用它。
在Unix下，我建议使用C-Kermit进行通用用途（特别是对于Kermit二进制协议下载（使用“loadb”命令）），并使用“cu”进行S-Record下载（使用“loads”命令）。
有关kermit的帮助，请参见https://www.denx.de/wiki/view/DULG/SystemSetup#Section_4.3.。
然而，如果您绝对想使用它，请尝试将此配置添加到“文件传输协议”部分：
NetBSD Notes:
=============
Starting at version 0.9.2, U-Boot supports NetBSD both as host
(build U-Boot) and target system (boots NetBSD/mpc8xx).
Building requires a cross environment; it is known to work on
NetBSD/i386 with the cross-powerpc-netbsd-1.3 package (you will also
need gmake since the Makefiles are not compatible with BSD make).
Note that the cross-powerpc package does not install include files;
attempting to build U-Boot will fail because <machine/ansi.h> is
missing. This file has to be installed and patched manually:
NetBSD 注意事项：
从版本0.9.2开始，U-Boot既支持NetBSD作为主机（构建U-Boot）也支持目标系统（引导NetBSD/mpc8xx）。
构建需要交叉环境；已知在NetBSD/i386上与cross-powerpc-netbsd-1.3软件包一起工作正常（您还需要gmake，因为Makefiles与BSD make不兼容）。
请注意，cross-powerpc软件包不会安装include文件；尝试构建U-Boot将失败，因为<machine/ansi.h>缺失。此文件需要手动安装和修补：
# cd /usr/pkg/cross/powerpc-netbsd/include
# mkdir powerpc
# ln -s powerpc machine
# cp /usr/src/sys/arch/powerpc/include/ansi.h powerpc/ansi.h
# ${EDIT} powerpc/ansi.h ## must remove __va_list, _BSD_VA_LIST
Native builds *don't* work due to incompatibilities between native
and U-Boot include files.
Booting assumes that (the first part of) the image booted is a
stage-2 loader which in turn loads and then invokes the kernel
proper. Loader sources will eventually appear in the NetBSD source
tree (probably in sys/arc/mpc8xx/stand/u-boot_stage2/); in the
meantime, see ftp://ftp.denx.de/pub/u-boot/ppcboot_stage2.tar.gz
本地构建不起作用，因为U-Boot的include文件与本地文件不兼容。
引导假设（引导的第一部分）加载的镜像是第二阶段加载器，该加载器将加载并调用真正的内核。加载器源代码最终将出现在NetBSD源代码树中
（可能在sys/arc/mpc8xx/stand/u-boot_stage2/目录下）；在此期间，请参阅 ftp://ftp.denx.de/pub/u-boot/ppcboot_stage2.tar.gz。
Implementation Internals:
=========================
The following is not intended to be a complete description of every
implementation detail. However, it should help to understand the
inner workings of U-Boot and make it easier to port it to custom
hardware.
好的，以下是对U-Boot内部实现细节的简要描述，旨在帮助读者理解其内部工作原理，并有助于将其移植到自定义硬件上。
Initial Stack, Global Data:
---------------------------
The implementation of U-Boot is complicated by the fact that U-Boot
starts running out of ROM (flash memory), usually without access to
system RAM (because the memory controller is not initialized yet).
This means that we don't have writable Data or BSS segments, and BSS
is not initialized as zero. To be able to get a C environment working
at all, we have to allocate at least a minimal stack. Implementation
options for this are defined and restricted by the CPU used: Some CPU
models provide on-chip memory (like the IMMR area on MPC8xx and
MPC826x processors), on others (parts of) the data cache can be
locked as (mis-) used as memory, etc.
初始堆栈和全局数据：
--------------
U-Boot的实现很复杂，因为U-Boot从ROM（闪存）开始运行，通常无法访问系统RAM（因为内存控制器尚未初始化）。
这意味着我们没有可写的数据或BSS段，并且BSS没有被初始化为零。为了能够获得一个C环境运行，我们必须分配至少一个最小堆栈。
这种实现的选项是由所使用的CPU定义的，并受到其限制：一些CPU模型提供片上存储器（如MPC8xx和MPC826x处理器上的IMMR区域），
在其他（parts of）数据缓存可以锁定为（mis-）用作存储器等。
Chris Hallinan posted a good summary of these issues to the
U-Boot mailing list:
Subject: RE: [U-Boot-Users] RE: More On Memory Bank x (nothingness)?
From: "Chris Hallinan" <clh@net1plus.com>
Date: Mon, 10 Feb 2003 16:43:46 -0500 (22:43 MET)
...
Correct me if I'm wrong, folks, but the way I understand it
is this: Using DCACHE as initial RAM for Stack, etc, does not
require any physical RAM backing up the cache. The cleverness
is that the cache is being used as a temporary supply of
necessary storage before the SDRAM controller is setup. It's
beyond the scope of this list to explain the details, but you
can see how this works by studying the cache architecture and
operation in the architecture and processor-specific manuals.
OCM is On Chip Memory, which I believe the 405GP has 4K. It
is another option for the system designer to use as an
initial stack/RAM area prior to SDRAM being available. Either
option should work for you. Using CS 4 should be fine if your
board designers haven't used it for something that would
cause you grief during the initial boot! It is frequently not
used.
CONFIG_SYS_INIT_RAM_ADDR should be somewhere that won't interfere
with your processor/board/system design. The default value
you will find in any recent u-boot distribution in
walnut.h should work for you. I'd set it to a value larger
than your SDRAM module. If you have a 64MB SDRAM module, set
it above 400_0000. Just make sure your board has no resources
that are supposed to respond to that address! That code in
start.S has been around a while and should work as is when
you get the config right.
-Chris Hallinan
DS4.COM, Inc.
克里斯·霍利南在U-Boot用户邮件列表中对此问题做了很好的总结：
主题：关于内存 bankx（什么都没有）的更多信息
发件人："克里斯·霍利南" mailto:clh@net1plus.com
日期：周一，2003年2月10日 16:43:46 -0500（22:43 MET）
...
伙计们，如果我没理解错的话，这是我的理解：使用DCACHE作为初始RAM（堆栈等）并不需要物理RAM来支持缓存。巧妙之处在于，在SDRAM控制器设置之前，
缓存被用作临时存储供应。在此列表之外，你可以通过研究缓存架构和处理器特定手册中的操作来了解其细节。
OCM是片上存储器，我相信405GP有4K。它是系统设计师在SDRAM可用之前的另一个选项，可以将其用作初始堆栈/RAM区域。这两种选项对你来说都应该可行。
如果你的电路板设计者没有将CS 4用于会让你在初始引导期间感到困扰的用途，那么使用它应该是可以的。它经常不被使用。
CONFIG_SYS_INIT_RAM_ADDR应该放在不会干扰你的处理器/电路板/系统设计的位置。你可以在任何最近的U-Boot分发版本中找到walnut.h中的默认值，
它应该对你有效。我建议将其设置为大于你的SDRAM模块的值。如果你有64MB的SDRAM模块，将其设置为高于400_0000。只要确保你的电路板没有响应该
地址的资源即可！start.S中的那段代码已经存在一段时间了，当你配置正确时，它应该可以正常工作。
-克里斯·霍利南
DS4.COM公司
It is essential to remember this, since it has some impact on the C
code for the initialization procedures:
* Initialized global data (data segment) is read-only. Do not attempt
to write it.
* Do not use any uninitialized global data (or implicitly initialized
as zero data - BSS segment) at all - this is undefined, initiali-
zation is performed later (when relocating to RAM).
* Stack space is very limited. Avoid big data buffers or things like
that.
Having only the stack as writable memory limits means we cannot use
normal global data to share information between the code. But it
turned out that the implementation of U-Boot can be greatly
simplified by making a global data structure (gd_t) available to all
functions. We could pass a pointer to this data as argument to _all_
functions, but this would bloat the code. Instead we use a feature of
the GCC compiler (Global Register Variables) to share the data: we
place a pointer (gd) to the global data into a register which we
reserve for this purpose.
重要的是要记住这一点，因为它对C代码的初始化程序有一些影响：
* 初始化的全局数据（数据段）是只读的。不要试图写入它。
* 不要使用任何未初始化的全局数据（或隐式初始化为零的数据 - BSS段） - 这是未定义的，初始化稍后执行（当重定位到RAM时）。
* 堆栈空间非常有限。避免使用大的数据缓冲区或类似的东西。
只有堆栈作为可写内存意味着我们不能使用正常的全局数据来在代码之间共享信息。但事实证明，通过使全局数据结构（gd_t）对所有函数可用，
U-Boot的实现可以大大简化。我们可以将该数据的指针传递给_所有_函数，但这样做会使代码膨胀。相反，我们使用GCC编译器的一个特性（全局
寄存器变量）来共享数据：我们将全局数据的指针（gd）放置在我们为此目的预留的寄存器中。
When choosing a register for such a purpose we are restricted by the
relevant (E)ABI specifications for the current architecture, and by
GCC's implementation.
在为该目的选择寄存器时，我们受到当前体系结构的（E）ABI规范和GCC实现的限制。
For PowerPC, the following registers have specific use: 对于PowerPC，以下寄存器具有特定用途：
R1: stack pointer
R2: reserved for system use
R3-R4: parameter passing and return values
R5-R10: parameter passing
R13: small data area pointer
R30: GOT pointer
R31: frame pointer
(U-Boot also uses R12 as internal GOT pointer. r12
is a volatile register so r12 needs to be reset when
going back and forth between asm and C)
（U-Boot还将R12用作内部GOT指针。r12是一个易失性寄存器，因此在C和asm之间来回移动时需要重置r12）
==> U-Boot will use R2 to hold a pointer to the global data
Note: on PPC, we could use a static initializer (since the
address of the global data structure is known at compile time),
but it turned out that reserving a register results in somewhat
smaller code - although the code savings are not that big (on
average for all boards 752 bytes for the whole U-Boot image,
624 text + 127 data).
注意：在PPC上，我们可以使用静态初始化程序（因为全局数据结构的地址在编译时已知），
但事实证明预留一个寄存器可以产生稍微较小的代码 - 尽管代码节省不是很大（对于所有
板子的平均值，整个U-Boot映像为752字节，文本为624字节+数据为127字节）。
On ARM, the following registers are used:
在ARM上,用到了以下寄存器
R0: function argument word/integer result
R1-R3: function argument word
R9: platform specific
R10: stack limit (used only if stack checking is enabled)
R11: argument (frame) pointer
R12: temporary workspace
R13: stack pointer
R14: link register
R15: program counter
==> U-Boot will use R9 to hold a pointer to the global data
Note: on ARM, only R_ARM_RELATIVE relocations are supported.
注意：在ARM上，只支持 R_ARM_RELATIVE 重定位。
On Nios II, the ABI is documented here:
https://www.altera.com/literature/hb/nios2/n2cpu_nii51016.pdf
==> U-Boot will use gp to hold a pointer to the global data
Note: on Nios II, we give "-G0" option to gcc and don't use gp
to access small data sections, so gp is free.
注意：在Nios II上，我们给gcc提供“-G0”选项，并且不使用gp来访问小数据段，因此gp是免费的。
On RISC-V, the following registers are used:
在RISC-V上,用到了以下寄存器
x0: hard-wired zero (zero)
x1: return address (ra)
x2: stack pointer (sp)
x3: global pointer (gp)
x4: thread pointer (tp)
x5: link register (t0)
x8: frame pointer (fp)
x10-x11: arguments/return values (a0-1)
x12-x17: arguments (a2-7)
x28-31: temporaries (t3-6)
pc: program counter (pc)
==> U-Boot will use gp to hold a pointer to the global data
Memory Management:
内存管理部分
------------------
U-Boot runs in system state and uses physical addresses, i.e. the
MMU is not used either for address mapping nor for memory protection.
The available memory is mapped to fixed addresses using the memory
controller. In this process, a contiguous block is formed for each
memory type (Flash, SDRAM, SRAM), even when it consists of several
physical memory banks.
U-Boot is installed in the first 128 kB of the first Flash bank (on
TQM8xxL modules this is the range 0x40000000 ... 0x4001FFFF). After
booting and sizing and initializing DRAM, the code relocates itself
to the upper end of DRAM. Immediately below the U-Boot code some
memory is reserved for use by malloc() [see CONFIG_SYS_MALLOC_LEN
configuration setting]. Below that, a structure with global Board
Info data is placed, followed by the stack (growing downward).
U-Boot运行在系统状态下，使用物理地址，也就是说MMU既不用于地址映射也不用于内存保护。
可用的内存被映射到固定的地址上，这个过程由内存控制器完成。在这个过程中，每种类型的内存（Flash、SDRAM、SRAM）都会形成一个连续的块，
即使它由几个物理内存 bank组成。
U-Boot被安装在第一个Flash bank的前128kB（在TQM8xxL模块中，范围是0x40000000 ... 0x4001FFFF）。
在启动、确定和初始化DRAM后，代码将自己重新定位到DRAM的上端。在U-Boot代码的下方，有一些内存被预留用于malloc()函数的使用
[请参考CONFIG_SYS_MALLOC_LEN配置设置]。再往下，放置了一个包含全局板信息数据的结构，后面紧跟着堆栈（向下增长）。
Additionally, some exception handler code is copied to the low 8 kB
of DRAM (0x00000000 ... 0x00001FFF).
So a typical memory configuration with 16 MB of DRAM could look like
this:
另外，一些异常处理程序代码被复制到DRAM的8kB低端（0x00000000 ... 0x00001FFF）。
所以一个典型的拥有16MB DRAM的内存配置可能如下所示：
0x0000 0000 Exception Vector code
:
0x0000 1FFF
0x0000 2000 Free for Application Use
:
:
:
:
0x00FB FF20 Monitor Stack (Growing downward) //监视器堆栈（向下增长）
0x00FB FFAC Board Info Data and permanent copy of global data //板卡信息数据和永久复制的全局数据
0x00FC 0000 Malloc Arena //Malloc Arena（预留空间, Arena 是指在U-Boot内存管理中，用于分配内存的连续区域
:
0x00FD FFFF
0x00FE 0000 RAM Copy of Monitor Code
... eventually: LCD or video framebuffer
... eventually: pRAM (Protected RAM - unchanged by reset)
0x00FF FFFF [End of RAM]
System Initialization:
u-boot 系统初始化
----------------------
In the reset configuration, U-Boot starts at the reset entry point
(on most PowerPC systems at address 0x00000100). Because of the reset
configuration for CS0# this is a mirror of the on board Flash memory.
To be able to re-map memory U-Boot then jumps to its link address.
To be able to implement the initialization code in C, a (small!)
initial stack is set up in the internal Dual Ported RAM (in case CPUs
which provide such a feature like), or in a locked part of the data
cache. After that, U-Boot initializes the CPU core, the caches and
the SIU.
Next, all (potentially) available memory banks are mapped using a
preliminary mapping. For example, we put them on 512 MB boundaries
(multiples of 0x20000000: SDRAM on 0x00000000 and 0x20000000, Flash
on 0x40000000 and 0x60000000, SRAM on 0x80000000). Then UPM A is
programmed for SDRAM access. Using the temporary configuration, a
simple memory test is run that determines the size of the SDRAM
banks.
When there is more than one SDRAM bank, and the banks are of
different size, the largest is mapped first. For equal size, the first
bank (CS2#) is mapped first. The first mapping is always for address
0x00000000, with any additional banks following immediately to create
contiguous memory starting from 0.
Then, the monitor installs itself at the upper end of the SDRAM area
and allocates memory for use by malloc() and for the global Board
Info data; also, the exception vector code is copied to the low RAM
pages, and the final stack is set up.
Only after this relocation will you have a "normal" C environment;
until that you are restricted in several ways, mostly because you are
running from ROM, and because the code will have to be relocated to a
new address in RAM.
U-Boot在复位配置中从复位入口点（大多数PowerPC系统上的地址为0x00000100）开始。由于针对CS0#的复位配置，
这是板上Flash内存的镜像，因此为了能够重新映射内存，U-Boot会跳转到它的链接地址。为了能够用C语言实现初
始化代码，需要设置一个（很小的！）初始堆栈，它位于内部双端口RAM中（以防CPU提供此类功能），或数据缓存
的一个锁定部分中。之后，U-Boot初始化CPU核心、缓存和SIU。
接下来，所有（潜在的）可用内存bank都会通过初步映射进行映射。例如，我们将它们放在512 MB的边界上
（SDRAM在0x00000000和0x20000000上，Flash在0x40000000和0x60000000上，SRAM在0x80000000上）。然后
为SDRAM访问编程UPM A。使用临时配置，运行一个简单的内存测试来确定SDRAM bank的大小。
当有多个SDRAM bank，并且这些 bank的大小不同时，首先映射最大的。对于大小相同的 bank，首先映射第一个bank（CS2#）。
第一个映射始终是针对地址0x00000000，任何额外的 bank都会紧随其后，以从0开始创建连续的内存。
然后，监视器将自己安装在SDRAM区域的上方，为malloc()分配内存并为全局板信息数据分配内存；还将异常向量代码复制到低RAM页面，并设置最后的堆栈。
只有在完成上述重新定位后，您才会拥有一个“正常”的C环境；在此之前，您会受到一些限制，主要是因为您是从ROM运行，并且代码将不得不被重新定位到RAM中的新地址。
U-Boot Porting Guide:
U-Boot移植指南：
----------------------
[Based on messages by Jerry Van Baren in the U-Boot-Users mailing
list, October 2002]
[基于2002年10月Jerry Van Baren在U-Boot-Users邮件列表中的消息]
int main(int argc, char *argv[])
{
sighandler_t no_more_time;
signal(SIGALRM, no_more_time);
alarm(PROJECT_DEADLINE - toSec (3 * WEEK));
if (available_money > available_manpower) {
Pay consultant to port U-Boot;
return 0;
}
Download latest U-Boot source;
Subscribe to u-boot mailing list;
if (clueless)
email("Hi, I am new to U-Boot, how do I get started?");
while (learning) {
Read the README file in the top level directory; //阅读顶层目录中的README文件；
Read https://www.denx.de/wiki/bin/view/DULG/Manual;
Read applicable doc/README.*;
Read the source, Luke; // 阅读源代码，卢克；
/* find . -name "*.[chS]" | xargs grep -i <keyword> */
}
if (available_money > toLocalCurrency ($2500))
Buy a BDI3000;
else
Add a lot of aggravation and time;
if (a similar board exists) { /* hopefully... */
cp -a board/<similar> board/<myboard>
cp include/configs/<similar>.h include/configs/<myboard>.h
} else {
Create your own board support subdirectory;
Create your own board include/configs/<myboard>.h file;
}
Edit new board/<myboard> files
Edit new include/configs/<myboard>.h
while (!accepted) {
while (!running) {
do {
Add / modify source code;
} until (compiles);
Debug;
if (clueless)
email("Hi, I am having problems...");
}
Send patch file to the U-Boot email list;
if (reasonable critiques)
Incorporate improvements from email list code review;
else
Defend code as written;
}
return 0;
}
void no_more_time (int sig)
{
hire_a_guru();
}
Coding Standards:
编码标准：
-----------------
All contributions to U-Boot should conform to the Linux kernel
coding style; see the kernel coding style guide at
https://www.kernel.org/doc/html/latest/process/coding-style.html, and the
script "scripts/Lindent" in your Linux kernel source directory.
Source files originating from a different project (for example the
MTD subsystem) are generally exempt from these guidelines and are not
reformatted to ease subsequent migration to newer versions of those
sources.
Please note that U-Boot is implemented in C (and to some small parts in
Assembler); no C++ is used, so please do not use C++ style comments (//)
in your code.
Please also stick to the following formatting rules:
- remove any trailing white space
- use TAB characters for indentation and vertical alignment, not spaces
- make sure NOT to use DOS '\r\n' line feeds
- do not add more than 2 consecutive empty lines to source files
- do not add trailing empty lines to source files
Submissions which do not conform to the standards may be returned
with a request to reformat the changes.
对U-Boot的所有贡献应符合Linux内核的编码风格；请参阅内核编码风格指南，访问https://www.kernel.org/doc/html/latest/process/coding-style.html，以及在您的Linux内核源代码目录中的脚本“scripts/Lindent”。
源自其他项目（例如MTD子系统）的源文件通常不受这些指南的限制，并且不会进行重新格式化以方便后续迁移到这些源的较新版本。
请注意，U-Boot使用C（以及少量汇编）实现，不使用C++，因此请不要在您的代码中使用C++风格注释（//）。
请遵守以下格式规则：
-删除任何尾部空格
-使用制表符进行缩进和对齐，而不是空格
-确保不使用DOS '\r\n'行尾
-不要在源文件中添加超过2个连续的空行
-不要在源文件的末尾添加尾随空行
-不符合标准的提交可能会被退回并要求重新格式化更改。
Submitting Patches:
提交补丁：
-------------------
Since the number of patches for U-Boot is growing, we need to
establish some rules. Submissions which do not conform to these rules
may be rejected, even when they contain important and valuable stuff.
由于U-Boot的补丁数量正在增加，我们需要建立一些规则。不符合这些规则的提交可能会被拒绝，即使它们包含重要和有价值的内容。
Please see https://www.denx.de/wiki/U-Boot/Patches for details.
请参阅https://www.denx.de/wiki/U-Boot/Patches了解详细信息。
Patches shall be sent to the u-boot mailing list <u-boot@lists.denx.de>;
see https://lists.denx.de/listinfo/u-boot
补丁应发送到u-boot邮件列表<u-boot@lists.denx.de>；请参阅https://lists.denx.de/listinfo/u-boot
When you send a patch, please include the following information with
it:
发送补丁时，请包含以下信息：
* For bug fixes: a description of the bug and how your patch fixes
this bug. Please try to include a way of demonstrating that the
patch actually fixes something.
对于错误修复：描述错误以及您的补丁如何修复该错误。请尽量包括一种证明该补丁实际上修复了某些内容的方法。
* For new features: a description of the feature and your
implementation.
对于新功能：描述该功能以及您的实现。
* For major contributions, add a MAINTAINERS file with your
information and associated file and directory references.
对于主要的贡献，请添加一个MAINTAINERS文件，其中包含您的信息以及相关的文件和目录引用。
* When you add support for a new board, don't forget to add a
maintainer e-mail address to the boards.cfg file, too.
当您为新板添加支持时，不要忘记在boards.cfg文件中添加维护人员的电子邮件地址。
* If your patch adds new configuration options, don't forget to
document these in the README file.
如果您的补丁添加了新的配置选项，请不要忘记在README文件中记录这些选项。
* The patch itself. If you are using git (which is *strongly*
recommended) you can easily generate the patch using the
"git format-patch". If you then use "git send-email" to send it to
the U-Boot mailing list, you will avoid most of the common problems
with some other mail clients.
If you cannot use git, use "diff -purN OLD NEW". If your version of
diff does not support these options, then get the latest version of
GNU diff.
The current directory when running this command shall be the parent
directory of the U-Boot source tree (i. e. please make sure that
your patch includes sufficient directory information for the
affected files).
We prefer patches as plain text. MIME attachments are discouraged,
and compressed attachments must not be used.
补丁本身。如果您正在使用git（强烈建议使用），则可以使用“ git format-patch”轻松生成补丁。如果您然后使用“ git send-email”将其发送到U-Boot邮件列表，您将避免一些其他邮件客户端的常见问题。
如果您不能使用git，请使用“diff -purN OLD NEW”。如果您的版本的diff不支持这些选项，请获取最新版本的GNU diff。
运行此命令时的当前目录应为U-Boot源代码树（即受影响文件的父目录）的父目录。
我们更喜欢纯文本形式的补丁。不推荐MIME附件，禁止压缩附件。
* If one logical set of modifications affects or creates several
files, all these changes shall be submitted in a SINGLE patch file.
如果一个逻辑修改集影响或创建了几个文件，所有这些更改应在一个单独的补丁文件中提交。
* Changesets that contain different, unrelated modifications shall be
submitted as SEPARATE patches, one patch per changeset.
包含不同、不相关修改的变化集应作为单独的补丁提交，每个变化集一个补丁。
Notes:
* Before sending the patch, run the buildman script on your patched
source tree and make sure that no errors or warnings are reported
for any of the boards.
* Keep your modifications to the necessary minimum: A patch
containing several unrelated changes or arbitrary reformats will be
returned with a request to re-formatting / split it.
* If you modify existing code, make sure that your new code does not
add to the memory footprint of the code ;-) Small is beautiful!
When adding new features, these should compile conditionally only
(using #ifdef), and the resulting code with the new feature
disabled must not need more memory than the old code without your
modification.
* Remember that there is a size limit of 100 kB per message on the
u-boot mailing list. Bigger patches will be moderated. If they are
reasonable and not too big, they will be acknowledged. But patches
bigger than the size limit should be avoided.
注意事项：
* 在发送补丁之前，请在您已修补的源代码树上运行buildman脚本，并确保没有任何错误或警告报告给任何板卡。
* 将修改保持到最低必要限度：包含几个不相关更改或任意重新格式化的补丁将被退回，并要求重新格式化/拆分。
* 如果您修改现有代码，请确保您的新代码不会增加代码的内存占用。小即是美！当添加新功能时，这些功能只应条件编译（使用#ifdef），禁用新功能后的代码不能占用比没有您的修改的旧代码更多的内存。
* 请记住，在u-boot邮件列表上每个消息有一个100kB大小的限制。大于100kB的补丁需要经过审核才能发送到邮件列表。如果它们是合理的并且不是太大，它们将被认可。但是，应避免超过大小限制的补丁。
【推荐】国内首个AI IDE，深度理解中文开发场景，立即下载体验Trae
【推荐】编程新体验，更懂你的AI，立即体验豆包MarsCode编程助手
【推荐】抖音旗下AI助手豆包，你的智能百科全书，全免费不限次数
【推荐】轻量又高性能的 SSH 工具 IShell：AI 加持，快人一步
· 记一次.NET内存居高不下排查解决与启示
· 探究高空视频全景AR技术的实现原理
· 理解Rust引用及其生命周期标识（上）
· 浏览器原生「磁吸」效果！Anchor Positioning 锚点定位神器解析
· 没有源码，如何修改代码逻辑？
· 分享4款.NET开源、免费、实用的商城系统
· 全程不用写代码，我用AI程序员写了一个飞机大战
· MongoDB 8.0这个新功能碉堡了，比商业数据库还牛
· 记一次.NET内存居高不下排查解决与启示
· 白话解读 Dapr 1.15：你的「微服务管家」又秀新绝活了