(1) console_init_f 是 console（控制台）的第一阶段初始化。_f 表示是第一阶段初始化，_r 表示第二阶段初始化。有时候初始化函数不能一次一起完成，中间必须要夹杂一些代码，因此将完整的一个模块的初始化分成了 2 个阶段。（我们的 uboot 中 start_armboot 的 826 行进行了 console_init_r 的初始化）
(2) console_init_f 在 uboot/common/console.c 中，仅仅是对 gd->have_console 设置为 1 而已，其他事情都没做。
(1) display_banner 用来串口输出显示 uboot 的 logo。
(2) display_banner 中使用 printf 函数向串口输出了 version_string 这个字符串。那么上面的分析表示， console_init_f 并没有初始化好 console， 怎么就可以 printf 了呢？
(3) 通过追踪 printf 的实现，发现 printf->puts，而 puts 函数中会判断当前 uboot 中 console 有没有被初始化好。
如果 console 初始化好了，则调用 fputs 完成串口发送（这条线才是控制台）；如果 console 尚未初始化好，则会调用 serial_puts (再调用 serial_putc 直接操作串口寄存器进行内容发送)。
(4) 控制台也是通过串口输出，非控制台也是通过串口输出。究竟什么是控制台？和不用控制台的区别？
实际上分析代码会发现，控制台就是一个用软件虚拟出来的设备，这个设备有一套专用的通信函数（发送、接收···），控制台的通信函数，最终会映射到硬件的通信函数中来实现。uboot 中，实际上控制台的通信函数是直接映射到硬件串口的通信函数中的，也就是说 uboot 中用没用控制台，其实并没有本质差别。
(5) 但是在别的体系中，控制台的通信函数映射到硬件通信函数时，可以用软件来做一些中间优化，譬如说缓冲机制。（操作系统中的控制台都使用了缓冲机制，所以有时候我们 printf 了内容，但是屏幕上并没有看到输出信息，就是因为被缓冲了。我们输出的信息只是到了 console 的 buffer 中，buffer 还没有被刷新到硬件输出设备上，尤其是在输出设备是LCD屏幕时）
(6) U_BOOT_VERSION 在 uboot 源代码中找不到定义，这个变量实际上是在 makefile 中定义的，然后在编译时生成的 include/version_autogenerated.h 中用一个宏定义来实现的。
(1) uboot启动过程中：
CPU: S5PV210@1000MHz(OK)
APLL = 1000MHz, HclkMsys = 200MHz, PclkMsys = 100MHz
MPLL = 667MHz, EPLL = 96MHz
HclkDsys = 166MHz, PclkDsys = 83MHz
HclkPsys = 133MHz, PclkPsys = 66MHz
SCLKA2M = 200MHz
Serial = CLKUART
这些信息都是 print_cpuinfo 打印出来的。
(2) 回顾 ARM 裸机中时钟配置一章的内容，比对这里调用的函数中计算各种时钟的方法，自己去慢慢分析体会这些代码的原理和实现方法。
(1) checkboard 看名字是检查、确认开发板的意思。这个函数的作用就是检查当前开发板是哪个开发板并且打印出开发板的名字。
(1) 这个函数实际没有被执行，X210 的 uboot 中并没有使用 I2C。如果将来我们的开发板要扩展 I2C 来接外接硬件，则在 x210_sd.h 中配置相应的宏即可开启。
(1) 对 uboot 源代码进行完修改（修改内容根据自己的理解和分析来修改）
(2) make distclean 然后 make x210_sd_config 然后 make。
make distclean
make x210_sd_config
make -j8
(3) 编译完成得到 u-boot.bin，然后去烧录。烧录方法按照 x210 刷机教程 讲的 linux 下使用 dd 命令来烧写的方法来烧写。
(4) 在 uboot_jiuding 文件夹下，就有 sd_fusing 烧录所需的文件。
注意，由于这个路径的文件是被九鼎官方编译过的，里面的文件是 64 bit 格式的；而我们的 linux 系统是 32 bit ，所以必须先make clean 清除后，重新编译生成文件。
烧写过程：
第一步：进入 sd_fusing 目录下
第二步：make clean
第三步：make
第四步：插入 SD 卡，ls /dev/sd* 得到 SD 卡在 ubuntu 中的设备号（一般是/dev/sdb，注意 SD 卡要连接到虚拟机 ubuntu 中，不要接到 windows 中）
注意，我们的 sd_fusing.sh 文件就是写的 /dev/sdb ，如有需要可以自行更改。
第五步：修改 sd_fusing.sh 文件：u-boot.bin.
./sd_fusing.sh /dev/sdb 完成烧录（注意不是 sd_fusing2.sh）。
(5) 总结：uboot 就是个庞大点复杂点的裸机程序而已，我们完全可以对他进行调试。调试的方法就是按照上面步骤，根据自己对代码的分析和理解对代码进行更改，然后重新编译烧录运行，根据运行结果来学习。
(1) dram_init 看名字是关于 DDR 的初始化。疑问：在汇编阶段已经初始化过 DDR 了，否则也无法 relocate 到这里的第二部分运行，怎么在这里又初始化 DDR ？
(2) dram_init 都是在给 gd->bd 里面关于 DDR 配置部分的全局变量赋值，让 gd->bd 数据记录下当前开发板的 DDR 的配置信息，以便uboot中使用内存。
(3) 从代码来看，其实就是初始化 gd->bd->bi_dram 这个结构体数组。
(1) 看名字意思就是打印显示 dram 的配置信息。
(2) 启动信息中的：（DRAM: 512 MB） 就是在这个函数中打印出来的。
思考：如何在 uboot 运行中得知 uboot 的 DDR 配置信息？uboot 中有一个命令叫 bdinfo ，这个命令可以打印出 gd->bd 中记录的所有硬件相关的全局变量的值，因此可以得知 DDR 的配置信息。
DRAM bank = 0x00000000
-> start = 0x30000000
-> size = 0x10000000
DRAM bank = 0x00000001
-> start = 0x40000000
-> size = 0x10000000
(1) 都是板级硬件的初始化以及 gd、gd->bd 中的数据结构的初始化。譬如：
网卡初始化、机器码（gd->bd->bi_arch_number）、内核传参 DDR 地址（gd->bd->bi_boot_params）、Timer4 初始化为 10ms 一次、波特率设置（gd->bd->bi_baudrate和gd->baudrate）、console 第一阶段初始化（gd->have_console 设置为 1 ）、打印uboot 的启动信息、打印 cpu 相关设置信息、检查并打印当前开发板名字、DDR 配置信息初始化（gd->bd->bi_dram）、打印 DDR 总容量。
(1) 虽然 NandFlash 和 NorFlash 都是 Flash，但是一般 NandFlash 会简称为 Nand 而不是 Flash，一般讲 Flash 都是指的 Norflash。这里的 2 行代码是 Norflash 相关的。
(2) flash_init 执行的是开发板中对应的 NorFlash 的初始化、display_flash_config 打印的也是 NorFlash 的配置信息（Flash: 8 MB 就是这里打印出来的）。但是实际上 X210 中是没有 Norflash 的。所以这两行代码是可以去掉的（我也不知道为什么没去掉？猜测原因有可能是去掉这两行代码，会导致别的地方工作不正常，需要花时间去移植调试，然后移植的人就懒得弄。实际上不去掉，除了显示有 8MB Flash 实际没用之外，也没有别的影响）
CONFIG_VFD 和 CONFIG_LCD 是显示相关的，这个是 uboot 中自带的 LCD 显示的软件架构。但是实际上我们用 LCD 而没有使用 uboot 中设置的这套软件架构，我们自己在后面自己添加了一个 LCD 显示的部分。
(1) mem_malloc_init 函数用来初始化 uboot 的堆管理器。
(2) uboot 中自己维护了一段堆内存，肯定自己就有一套代码来管理这个堆内存。有了这些东西 uboot 中你也可以 malloc、free 这套机制来申请内存和释放内存。我们在 DDR 内存中给堆预留了 896KB 的内存。
结论：加上CONFIG_NOFLASH 宏之后编译出错，说明代码移植的不好，那个文件的包含没有被这个宏控制。于是乎移植的人就直接放这没管。
(1) 从536 到 768 行，是开发板独有的初始化。意思是三星用一套 uboot 同时满足了好多个系列型号的开发板，然后在这里把不同开发板自己独有的一些初始化写到了这里。用 #if 条件编译配合 CONFIG_xxx 宏来选定特定的开发板。
(2) X210 相关的配置在 599 行到 632 行。
(3) mmc_initialize 看名字就应该是 MMC 相关的一些基础的初始化，其实就是用来初始化 SoC 内部的 SD/MMC 控制器的。函数在 uboot/drivers/mmc/mmc.c 里。
(4) uboot 中对硬件的操作（譬如网卡、SD 卡···）都是借用的 linux 内核中的驱动来实现的，uboot 根目录底下有个 drivers 文件夹，这里面放的全都是从 linux 内核中移植过来的各种驱动源文件。
(5) mmc_initialize 是具体硬件架构无关的一个 MMC 初始化函数，所有的使用了这套架构的代码，都调用这个函数来完成 MMC 的初始化。mmc_initialize 中再调用 board_mmc_init 和 cpu_mmc_init 来完成具体的硬件的 MMC 控制器初始化工作。
(6) cpu_mmc_init 在 uboot/cpu/s5pc11x/cpu.c 中，这里面又间接的调用了 drivers/mmc/s3c_mmcxxx.c 中的驱动代码来初始化硬件 MMC 控制器。这里面分层很多，分层的思想一定要有，否则完全就糊涂了。
(1) env_relocate 是环境变量的重定位，完成从 SD 卡中将环境变量读取到 DDR 中的任务。
(2) 环境变量到底从哪里来？SD 卡中有一些（8个）独立的扇区作为环境变量存储区域的。但是我们烧录/部署系统时，我们只是烧录了 uboot 分区、kernel 分区和 rootfs 分区，根本不曾烧录 env 分区。
所以当我们烧录完系统，第一次启动时 ENV 分区是空的，本次启动 uboot 尝试去 SD 卡的 ENV 分区读取环境变量时失败（读取回来后进行 CRC 校验时失败），我们 uboot 选择从 uboot 内部代码中设置的一套默认的环境变量出发来使用（这就是默认环境变量）。
这套默认的环境变量在本次运行时，会被读取到 DDR 中的环境变量中，然后被写入（也可能是你saveenv时写入，也可能是uboot设计了第一次读取默认环境变量后就写入）SD 卡的 ENV 分区。然后下次再次开机时，uboot 就会从 SD 卡的 ENV 分区读取环境变量到 DDR 中，这次读取就不会失败了。
(3) 真正的从 SD 卡到 DDR 中重定位 ENV 的代码是在 env_relocate_spec 内部的 movi_read_env 完成的。
(1) 开发板的 IP 地址是在 gd->bd 中维护的，来源于环境变量 ipaddr。 getenv 函数用来获取字符串格式的 IP 地址，然后用 string_to_ip 将字符串格式的 IP 地址转成字符串格式的点分十进制格式。
(2) IP 地址由 4 个 0-255 之间的数字组成，因此一个 IP 地址在程序中最简单的存储方法就是一个 unsigend int 。但是人类容易看懂的并不是这种类型，而是点分十进制类型（192.168.1.2）。这两种类型可以互相转换。
(1) devices_init 看名字就是设备的初始化。这里的设备指的就是开发板上的硬件设备。放在这里初始化的设备都是驱动设备，这个函数本来就是从驱动框架中衍生出来的。uboot 中很多设备的驱动是直接移植 linux 内核的（譬如网卡、SD卡），linux 内核中的驱动都有相应的设备初始化函数。linux 内核在启动过程中就有一个 devices_init (名字不一定完全对，但是差不多)，作用就是集中执行各种硬件驱动的 init 函数。
(2) uboot 的这个函数其实就是从 linux 内核中移植过来的，它的作用也是去执行所有的从 linux 内核中继承来的那些硬件驱动的初始化函数。
(1) jumptable 跳转表，本身是一个函数指针数组，里面记录了很多函数的函数名。看这阵势是要实现一个函数指针到具体函数的映射关系，将来通过跳转表中的函数指针就可以执行具体的函数。这个其实就是在用 C 语言实现面向对象编程。在 linux 内核中有很多这种技巧。
(2) 通过分析发现跳转表只是被赋值从未被引用，因此跳转表在 uboot 中根本就没使用。
(1) console_init_f 是控制台的第一阶段初始化，console_init_r 是第二阶段初始化。实际上第一阶段初始化并没有实质性工作，第二阶段初始化才进行了实质性工作 。
(2) console_init_r 就是 console 的纯软件架构方面的初始化（说白了就是去给 console 相关的数据结构中填充相应的值），所以属于纯软件配置类型的初始化。
(4) uboot 的 console 实际上并没有干有意义的转化，它就是直接调用的串口通信的函数。所以用不用 console 实际并没有什么分别。（在 linux 内 console 就可以提供缓冲机制等不用 console 不能实现的东西）。
(1) 看名字应该是中断初始化代码。这里指的是 CPSR 中总中断标志位的使能。
(2) 因为我们 uboot 中没有使用中断，因此没有定义 CONFIG_USE_IRQ 宏，因此我们这里这个函数是个空壳子。
(3) uboot 中经常出现一种情况就是，根据一个宏是否定义了来条件编译决定是否调用一个函数内部的代码。uboot 中有 2 种解决方案来处理这种情况：方案一：在调用函数处使用条件编译，然后函数体实际完全提供代码。方案二：在调用函数处直接调用，然后在函数体处提供 2 个函数体，一个是有实体的一个是空壳子，用宏定义条件编译来决定实际编译时编译哪个函数进去。
(1) 这两个环境变量都是内核启动有关的，在启动 linux 内核时会参考这两个环境变量的值。
(1) 看名字这个函数就是开发板级别的一些初始化里比较晚的了，就是晚期初始化。所以晚期就是前面该初始化的都初始化过了，剩下的一些必须放在后面初始化的就在这里了。侧面说明了开发板级别的硬件软件初始化告一段落了。
(2) 对于 X210 来说，这个函数是空的。
(1) 看名字应该是网卡相关的初始化。这里不是 SoC 与网卡芯片连接时，SoC 这边的初始化，而是网卡芯片本身的一些初始化。
(2) 对于 X210（DM9000）来说，这个函数是空的。X210 的网卡初始化在 board_init 函数中，网卡芯片的初始化在驱动中。
(1) x210 开发板在启动起来之前的一些初始化，以及 LCD 屏幕上的 logo 显示。
(1) uboot 启动的最后阶段设计了一个自动更新的功能。就是：我们可以将要升级的镜像放到 SD 卡的固定目录中，然后开机时在 uboot 启动的最后阶段检查升级标志（是一个按键。按键中标志为 “LEFT” 的那个按键，这个按键如果按下则表示 update mode，如果启动时未按下则表示 boot mode）。如果进入 update mode，则 uboot 会自动从 SD 卡中读取镜像文件然后烧录到 iNand 中；如果进入 boot mode ，则 uboot 不执行 update，直接启动正常运行。
(2) 这种机制能够帮助我们快速烧录系统，常用于量产时用 SD 卡进行系统烧录部署。
(1) 解析器
(2) 开机倒数自动执行
(3) 命令补全
(1) 第二阶段主要是对开发板级别的硬件、软件数据结构进行初始化。
(2) 代码流程顺序
init_sequence
cpu_init 空的
board_init 网卡、机器码、内存传参地址
dm9000_pre_init 网卡
gd->bd->bi_arch_number 机器码
gd->bd->bi_boot_params 内存传参地址
interrupt_init 定时器
env_init
init_baudrate gd数据结构中波特率
serial_init 空的
console_init_f 空的
display_banner 打印启动信息
print_cpuinfo 打印CPU时钟设置信息
checkboard 检验开发板名字
dram_init gd数据结构中DDR信息
display_dram_config 打印DDR配置信息表
mem_malloc_init 初始化uboot自己维护的堆管理器的内存
mmc_initialize inand/SD卡的SoC控制器和卡的初始化
env_relocate 环境变量重定位
gd->bd->bi_ip_addr gd数据结构赋值
gd->bd->bi_enetaddr gd数据结构赋值
devices_init 空的
jumptable_init 不用关注的
console_init_r 真正的控制台初始化
enable_interrupts 空的
loadaddr、bootfile 环境变量读出初始化全局变量
board_late_init 空的
eth_initialize 空的
x210_preboot_init LCD初始化和显示logo
check_menu_update_from_sd 检查自动更新
main_loop 主循环
(1) 第一阶段为汇编阶段、第二阶段为 C 阶段；
(2) 第一阶段在 SRAM 中、第二阶段在 DRAM 中；
(3) 第一阶段注重 SoC 内部、第二阶段注重 SoC 外部 Board 内部；
(1) x210_sd.h 头文件中的宏定义；
(2) 特定硬件的初始化函数位置（譬如网卡）。
源自朱有鹏老师.