一.uboot启动第二阶段之start_armboot函数简介
1.start_armboot函数简介
(1)这个函数在uboot/lib_arm/board.c的第444行开始到908行结束。
(2)、即一个函数组成uboot第二阶段
2、宏观分析：uboot第二阶段应该做什么
(1)概括来讲uboot第一阶段主要就是初始化了SoC内部的一些部件（譬如看门狗、时钟），然后初始化DDR并且完成重定位。
(2)由宏观分析来讲，uboot的第二阶段就是要初始化剩下的还没被初始化的硬件。主要是SoC外部硬件（譬如iNand、网卡芯片····）、uboot本身的一些东西（uboot的命令、环境变量等····）。然后最终初始化完必要的东西后进入uboot的命令行准备接受命令。
3.、思考：uboot第二阶段完结于何处？（回忆uboot初体验章节）
(1)uboot启动后自动运行打印出很多信息（这些信息就是uboot在第一和第二阶段不断进行初始化时，打印出来的信息）。然后uboot进入了倒数bootdelay秒然后执行bootcmd对应的启动命令。
(2)如果用户没有干涉则会执行bootcmd进入自动启动内核流程（uboot就死掉了）；此时用户可以按下回车键打断uboot的自动启动进入uboot的命令行下。然后uboot就一直工作在命令行下。
(3)uboot的命令行就是一个死循环，循环体内不断重复：接收命令、解析命令、执行命令。这就是uboot最终的归宿。
二.uboot启动第二阶段之start_armboot函数解析1
1.DECLARE_GLOBAL_DATA_PTR宏定义
(1)#define DECLARE_GLOBAL_DATA_PTR register volatile gd_t *gd asm (“r8”)
定义了一个全局变量名字叫gd,这个全局变量是一个指针类型，占4字节。用volatile修饰表示可变的，用register修饰表示这个变量要尽量放到寄存器中，后面的asm(“r8”)是gcc支持的一种语法，意思就是要把gd放到寄存器r8中。
(2)综合分析，DECLARE_GLOBAL_DATA_PTR就是定义了一个要放在寄存器r8中的全局变量，名字叫gd，类型是一个指向gd_t类型变量的指针。
(3)为什么要定义为register？
因为这个全局变量gd（global
data的简称）是uboot中很重要的一个全局变量（准确的说这个全局变量是一个结构体，里面有很多内容，这些内容加起来构成的结构体就是uboot中常用的所有的全局变量），这个gd在程序中经常被访问，因此放在register中提升效率。因此纯粹是运行效率方面考虑，和功能要求无关。并不是必须的。
(4)gd_t定义在include/asm-arm/global_data.h中。
gd_t中定义了很多全局变量，都是整个uboot使用的；其中有一个bd_t类型的指针，指向一个bd_t类型的变量，这个bd是开发板的板级信息的结构体，里面有不少硬件。
三.uboot启动第二阶段之start_armboot函数解析内存分布
1、为什么要分配内存
(1)DECLARE_GLOBAL_DATA_PTR只是定义了一个指针，也就是说gd里的这些全局变量并没有被分配内存，我们在使用gd之前要给他分配内存，否则gd也只是一个野指针而已。
(2)gd和bd需要内存，内存当前没有被人管理（因为没有操作系统统一管理内存），大片的DDR内存散放着可以随意使用（只要使用内存地址直接去访问内存即可）。但是因为uboot中后续很多操作还需要大片的连着内存块，因此这里使用内存要本着够用就好，紧凑排布的原则。所以我们在uboot中需要有一个整体规划。
下面分析这块内存分布
(3)上图最后的内存间隔（c语言中嵌套汇编的用法），作用是为了防止高版本的gcc的优化造成错误。
2、内存排布
(1)uboot区
CFG_UBOOT_BASE-xx（CFG_UBOOT_SIZE为2M，长度为uboot的实际长度），如果移植内存不够时，可改此处分配内存大小
(2)堆区 长度为CFG_MALLOC_LEN，实际为912KB
(3)栈区 长度为CFG_STACK_SIZE，实际为512KB
(4)gd 长度为sizeof(gd_t)，实际36字节
(5)bd 长度为sizeof(bd_t)，实际为44字节左右
（6）内存分布图如下
四.uboot启动第二阶段之start_armboot函数解析2（board_init函数分析）
1、for循环执行init_sequence
(1)init_sequence是一个函数指针数组，数组中存储了很多个函数指针，这些指向指向的函数都是init_fnc_t类型（特征是接收参数是void类型，返回值是int）。
(2)init_sequence在定义时就同时给了初始化，初始化的函数指针都是一些函数名。
(3)init_fnc_ptr是一个二重函数指针，可以指向init_sequence这个函数指针数组。
(4)用for循环肯定是想要去遍历这个函数指针数组（遍历的目的也是去依次执行这个函数指针数组中的所有函数）。思考：如何遍历一个函数指针数组？有2种方法：第一种也是最常用的一种，用下标去遍历，用数组元素个数来截至。第二种不常用，但是也可以。就是在数组的有效元素末尾放一个标志，依次遍历到标准处即可截至（有点类似字符串的思路）。
我们这里使用了第二种思路。因为数组中存的全是函数指针，因此我们选用了NULL来作为标志。我们遍历时从开头依次进行，直到看到NULL标志截至。这种方法的优势是不用事先统计数组有多少个元素。
(5)init_fnc_t的这些函数的返回值定义方式一样的，都是：函数执行正确时返回0，不正确时返回-1.所以我们在遍历时去检查函数返回值，如果遍历中有一个函数返回值不等于0则hang()挂起。从分析hang函数可知：uboot启动过程中初始化板级硬件时不能出任何错误，只要有一个错误整个启动就终止，除了重启开发板没有任何办法。
(6)init_sequence中的这些函数，都是board（开发板）级别的各种硬件初始化。
2、cpu_init
(1)看名字这个函数应该是cpu内部的初始化，所以这里是空的。
3、board_init
(1)board_init在uboot/board/samsung/x210/x210.c中，这个看名字就知道是x210开发板相关的初始化。
(2)DECLARE_GLOBAL_DATA_PTR在这里声明是为了后面使用gd方便。可以看出把gd的声明定义成一个宏的原因就是我们要到处去使用gd，因此就要到处声明，定义成宏比较方便。
(3)网卡初始化。CONFIG_DRIVER_DM9000这个宏是x210_sd.h中定义的，这个宏用来配置开发板的网卡的。dm9000_pre_init函数就是对应的DM9000网卡的初始化函数。开发板移植uboot时，如果要移植网卡，主要的工作就在这里。
(4)这个函数中主要是网卡的GPIO和端口的配置，而不是驱动。因为网卡的驱动都是现成的正确的，移植的时候驱动是不需要改动的，关键是这里的基本初始化。因为这些基本初始化是硬件相关的。
五.uboot启动第二阶段之start_armboot函数解析3（board_init函数分析）
1、gd->bd->bi_arch_number
(1)bi_arch_number是board_info中的一个元素，含义是：开发板的机器码。所谓机器码就是uboot给这个开发板定义的一个唯一编号。
(2)机器码的主要作用就是在uboot和linux内核之间进行比对和适配。
(3)linux做了个设置：给每个开发板做个唯一编号（机器码），然后在uboot、linux内核中都有一个软件维护的机器码编号。然后开发板、uboot、linux三者去比对机器码，如果机器码对上了就启动，否则就不启动（因为软件认为我和这个硬件不适配）。
(4)MACH_TYPE在x210_sd.h中定义，值是2456，并没有特殊含义，只是当前开发板对应的编号。这个编号就代表了x210这个开发板的机器码，将来这个开发板上面移植的linux内核中的机器码也必须是2456，否则就启动不起来。
(5)uboot中配置的这个机器码，会作为uboot给linux内核的传参的一部分传给linux内核，内核启动过程中会比对这个接收到的机器码，和自己本身的机器码相对比，如果相等就启动，如果不想等就不启动。
(6)理论上来说，一个开发板的机器码不能自己随便定。用来学习只要保证uboot和kernel（linux内核）中的编号是一致的，就不影响自己的开发板启动。
2、gd->bd->bi_boot_params
(1)bd_info中另一个主要元素，bi_boot_params表示uboot给linux
kernel启动时的传参的内存地址。也就是说uboot给linux内核传参的时候是这么传的：uboot事先将准备好的传参（字符串，就是bootargs）放在内存的一个地址处（就是bi_boot_params），然后uboot就启动了内核（uboot在启动内核时真正是通过寄存器r0
r1 r2来直接传递参数的，其中有一个寄存器中bi_boot_params）。
内核启动后从寄存器中读取bi_boot_params就知道了uboot给我传递的参数到底在内存的哪里。然后自己去内存的那个地方去找bootargs。
(2)经过计算得知：X210中bi_boot_params的值为0x30000100，这个内存地址就被分配用来做内核传参了。所以在uboot的其他地方使用内存时要注意，千万不敢把这里给淹没了。
(3)PHYS_SDRAM_1是DDR中的一些属性配置，为什么这里又在配置DDR？
注意：这里的初始化DDR和汇编阶段lowlevel_init中初始化DDR是不同的。当时是硬件的初始化，目的是让DDR可以开始工作。现在是软件结构中一些DDR相关的属性配置、地址设置的初始化，是纯软件层面的。
软件层次初始化DDR的原因：对于uboot来说，他怎么知道开发板上到底有几片DDR内存，每一片的起始地址、长度这些信息呢？在uboot的设计中采用了一种简单直接有效的方式：程序员在移植uboot到一个开发板时，程序员自己在x210_sd.h中使用宏定义去配置出来板子上DDR内存的信息，然后uboot只要读取这些信息即可
x210_sd.h的500行到506行中使用了标准的宏定义来配置DDR相关的参数。主要配置了如下信息：有几片DDR内存、每一片DDR的起始地址、长度。这里的配置信息我们在uboot代码中使用到内存时就可以从这里提取使用
六.uboot启动第二阶段之start_armboot函数解析4（interrupt_init函数分析）
1、interrupt_init
(1)看名字函数是和中断初始化有关的，但是实际上不是，实际上这个函数是用来初始化定时器的（实际使用的是Timer4）。
(2)裸机中讲过：210共有5个PWM定时器。其中Timer0-timer3都有一个对应的PWM信号输出的引脚。而Timer4没有引脚，无法输出PWM波形。Timer4在设计的时候就不是用来输出PWM波形的（没有引脚，没有TCMPB寄存器），这个定时器被设计用来做计时。
(3)Timer4用来做计时时要使用到2个寄存器：TCNTB4、TCNTO4。TCNTB中存了一个数，这个数就是定时次数（每一次时间是由时钟决定的，其实就是由2级时钟分频器决定的）。我们定时时只需要把定时时间/基准时间=数，将这个数放入TCNTB中即可；我们通过TCNTO寄存器即可读取时间有没有减到0，读取到0后就知道定的时间已经到了。
(4)使用Timer4来定时，因为没有中断支持，所以CPU不能做其他事情同时定时，CPU只能使用轮询方式来不断查看TCNTO寄存器才能知道定时时间到了没。因为Timer4的定时是不能实现微观上的并行。uboot中定时就是通过Timer4来实现定时的。所以uboot中定时时不能做其他事（考虑下，典型的就是bootdelay，bootdelay中实现定时并且检查用户输入是用轮询方式实现的，原理参考裸机中按键章节中的轮询方式处理按键）
(5)interrupt_init函数将timer4设置为定时10ms。关键部位就是get_PCLK函数获取系统设置的PCLK_PSYS时钟频率，然后设置TCFG0和TCFG1进行分频，然后计算出设置为10ms时需要向TCNTB中写入的值，将其写入TCNTB，然后设置为auto
reload模式，然后开定时器开始计时就没了。
总结：在学习这个函数时，注意标准代码和之前裸机代码中的区别，重点学会：通过定义结构体的方式来访问寄存器，通过函数来自动计算设置值以设置定时器。
2、env_init
(1)env_init，看名字就知道是和环境变量有关的初始化。
(2)为什么有很多env_init函数，主要原因是uboot支持各种不同的启动介质（譬如norflash、nandflash、inand、sd卡·····），我们一般从哪里启动就会把环境变量env放到哪里。而各种介质存取操作env的方法都是不一样的。因此uboot支持了各种不同介质中env的操作方法。所以有好多个env_xx开头的c文件。实际使用的是哪一个要根据自己开发板使用的存储介质来定（这些env_xx.c同时只有1个会起作用，其他是不能进去的，通过x210_sd.h中配置的宏来决定谁被包含的），对于x210来说，使用的inand,我们应该看env_movi.c中的函数。
(3)经过基本分析，这个函数只是对内存里维护的那一份uboot的env做了基本的初始化或者说是判定（判定里面有没有能用的环境变量）。当前因为我们还没进行环境变量从SD卡到DDR中的relocate，因此当前环境变量是不能用的
(4)在start_armboot函数中（776行）调用env_relocate才进行环境变量从SD卡中到DDR中的重定位。重定位之后需要环境变量时才可以从DDR中去取，重定位之前如果要使用环境变量只能从SD卡中去读取。
七.uboot启动第二阶段之start_armboot函数解析5
1、init_baudrate
(1)init_baudrate看名字就是初始化串口通信的波特率的。
(2)getenv_r函数用来读取环境变量的值。用getenv函数读取环境变量中“baudrate”的值（注意读取到的不是int型而是字符串类型），然后用simple_strtoul函数将字符串转成数字格式的波特率。
(3)baudrate初始化时的规则是：先去环境变量中读取”baudrate”这个环境变量的值。如果读取成功则使用这个值作为环境变量，记录在gd->baudrate和gd->bd->bi_baudrate中；
如果读取不成功则使用x210_sd.h中的CONFIG_BAUDRATE的值作为波特率。
从这可以看出：环境变量的优先级是很高的。
2、serial_init
(1)serial_init看名字是初始化串口的。（疑问：start.S中调用的lowlevel_init.S中已经使用汇编初始化过串口了，这里怎么又初始化？这两个初始化是重复的还是各自有不同？）
(2)SI中可以看出uboot中有很多个serial_init函数，我们使用的是uboot/cpu/s5pc11x/serial.c中的serial_init函数。
(3)进来后发现serial_init函数其实什么都没做。因为在汇编阶段串口已经被初始化过了，因此这里就不再进行硬件寄存器的初始化了。
八.uboot启动第二阶段之start_armboot函数解析6
1、console_init_f
(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而已，其他事情都没做。
所以，就目前的初始化，控制台还是不能用的！
2、display_banner
(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)U_BOOT_VERSION在uboot源代码中找不到定义，这个变量实际上是在makefile中定义的，然后在编译时生成的include/version_autogenerated.h中用一个宏定义来实现的。（前面编译配置讲过）
3、print_cpuinfo
(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裸机中时钟配置一章的内容，比对这里调用的函数中计算各种时钟的方法，自己去慢慢分析体会这些代码的原理和实现方法。这就是学习。
九.uboot启动第二阶段之start_armboot函数解析7
1、checkboard函数
(1)checkboard看名字是检查、确认开发板的意思。这个函数的作用就是检查当前开发板是哪个开发板并且打印出开发板的名字。
2、init_func_i2c
(1)这个函数实际没有被执行，X210的uboot中并没有使用I2C。如果将来我们的开发板要扩展I2C来接外接硬件，则在x210_sd.h中配置相应的宏即可开启。
3、uboot学习实践
(1)对uboot源代码进行完修改（修改内容根据自己的理解和分析来修改）
这里，我们简单的修改一下Makefil
(2)依次输入命令：make distclean 》》make x210_sd_config 》》make
(3)编译完成得到u-boot.bin，然后去烧录。烧录方法按照裸机第三部分讲的linux下使用dd命令来烧写的方法来烧写。
(4)烧写过程：
第一步：进入sd_fusing目录下
第二步：make clean(这里为什么要make
clean,是为了从新初始化烧录工具为我们的编译环境，默认的是x64的环境，故需要清除)
第三步：make
第四步：插入sd卡，ls /dev/sd*
得到SD卡在ubuntu中的设备号（一般是/dev/sdb，注意SD卡要连接到虚拟机ubuntu中，不要接到windows中）
第五步：./sd_fusing.sh /dev/sdb完成烧录（注意不是sd_fusing2.sh）
(5)总结：uboot就是个庞大点复杂点的裸机程序而已，我们完全可以对他进行调试。调试的方法就是按照上面步骤，根据自己对代码的分析和理解对代码进行更改，然后重新编译烧录运行，根据运行结果来学习。
烧写Uboot到SD卡遇到的问题1：
打开 sd_mbr.bat 失败，打开 SD-bl1-8k.bin 失败，failed to open’SD-bl1-8k.bin’,
查看sd_fusing.sh内容：
修改为：
然后从新按照烧录过程来一边即可。
烧录成功
问题2：烧录成功后，开发板SD卡启动后，终端打印的信息还是没有任何变化？
分析后，首先得出，修改后的uboot在开发板根本没有启动起来，原因是SD卡根本没有启动起来，相当于没有SD卡。
最终解决的方法是，在uboot底下擦除该uboot，然后从新启动开发板，成功！
在uboot底下如何擦除uboot：movi write u-boot 0x30000000，如下图
插上事先烧写好的bin文件的SD卡，重启开发板，显示如下，修改logo成功！
十.uboot启动第二阶段之start_armboot函数解析8
1、dram_init
(1)dram_init看名字是关于DDR的初始化。疑问：在汇编阶段已经初始化过DDR了否则也无法relocate到第二部分运行，怎么在这里又初始化DDR？
(2)dram_init都是在给gd->bd里面关于DDR配置部分的全局变量赋值，让gd->bd数据记录下当前开发板的DDR的配置信息，以便uboot中使用内存。
(3)从代码来看，其实就是初始化gd->bd->bi_dram这个结构体数组。
2、display_dram_config
(1)看名字意思就是打印显示dram的配置信息。
(2)启动信息中的：（DRAM: 512 MB）就是在这个函数中打印出来的。
(3)思考：如何在uboot运行中得知uboot的DDR配置信息？
uboot中有一个命令叫bdinfo，这个命令可以打印出gd->bd中记录的所有硬件相关的全局变量的值，因此可以得知DDR的配置信息。
DRAM bank = 0x00000000
-> start = 0x30000000
-> size = 0x10000000
DRAM bank = 0x00000001
-> start = 0x40000000
-> size = 0x10000000
3.uboot启动第二阶段之init_sequence函数指针数组总结
(1)都是板级硬件的初始化以及gd、gd->bd中的数据结构的初始化。譬如：
board_init函数：网卡初始化、机器码（gd->bd->bi_arch_number）、内核传参DDR地址（gd->bd->bi_boot_params）、
interrupt_init函数：Timer4初始化为10ms一次、
init_baudrate函数：波特率设置（gd->bd->bi_baudrate和gd->baudrate）、
console_init_f函数：console第一阶段初始化（gd->have_console设置为1）、
display_banner函数：打印uboot的启动信息、
print_cpuinfo函数：打印cpu时钟相关设置信息、
checkboard函数 ：检查并打印当前开发板名字、
dram_init函数：DDR配置信息初始化（gd->bd->bi_dram）、打印DDR总容量。
display_dram_config函数：打印DDR配置信息表
总结回顾：本节课结束后已经到了start_armboot的第487行。
下一节才是start_armboot函数本身的具体分析。
1805
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
