uboot源码分析(基于S5PV210)之启动第二阶段

uboot系列文章所用源码(我的开发板厂商提供的)：

链接：https://pan.baidu.com/s/1gzjMjV5gUFlwKSnOfPwX_A 
提取码：kw31 
--来自百度网盘超级会员V6的分享

一、start_armboot函数简介

1、一个很长的函数

(1)这个函数在uboot/lib_arm/board.c的第444行开始到908行结束。

(2)这464行还不是全部，因为里面还调用了别的函数。

(3)为什么这么长的函数，怎么不分成两三个函数？
  主要因为这个函数整个构成了uboot启动的第二阶段。

2、一个函数组成uboot第二阶段

  从汇编阶段进入C语言阶段，第一阶段基本都是使用汇编代码实现的，第二阶段开始使用C语言进行开发。

3、宏观分析：uboot第二阶段应该做什么

(1)概括来讲uboot第一阶段主要就是初始化了SoC内部的一些部件（譬如看门狗、时钟），然后初始化DDR并且完成重定位。

(2)由宏观分析来讲，uboot的第二阶段就是要初始化剩下的还没被初始化的硬件。主要是SoC外部硬件（譬如iNand、网卡芯片····）、uboot本身的一些东西（uboot的命令、环境变量等····）。然后最终初始化完必要的东西后进入uboot的命令行准备接受命令。

4、思考：uboot第二阶段完结于何处？

(1)uboot启动后自动运行打印出很多信息（这些信息就是uboot在第一和第二阶段不断进行初始化时，打印出来的信息）。然后uboot进入了倒数bootdelay秒后执行bootcmd对应的启动命令。

(2)如果用户没有干涉则会执行bootcmd进入自动启动内核流程（uboot就死掉了）；此时用户可以按下回车键 ( 有的uboot可能是其他按键，这个是不固定的，可以在uboot代码中进行修改 ) 打断uboot的自动启动进入uboot的命令行下。然后uboot就一直工作在命令行下，解析命令行的输入执行不同的命令。

(3)uboot的命令行就是一个死循环，循环体内不断重复：接收命令、解析命令、执行命令。这就是uboot最终的归宿。

二、start_armboot解析

1、init_fnc_t

(1)typedef int (init_fnc_t) (void);	这是一个函数类型

(2)init_fnc_ptr是一个二重函数指针，二重指针的作用有2个：其中一个是用来指向一重指
针，一个是用来指向指针数组。因此这里的init_fuc_ptr可以用来指向一个函数指针数组。

2、DECLARE_GLOBAL_DATA_PTR

#define DECLARE_GLOBAL_DATA_PTR     register volatile gd_t *gd asm ("r8")

定义了一个全局变量名字叫gd,这个全局变量是一个指针类型，占4字节。用volatile修饰
表示可变的，用register修饰表示这个变量要尽量放到寄存器中，后面的asm("r8")是gcc
支持的一种语法，意思就是要把gd放到寄存器r8中。

  综合分析，DECLARE_GLOBAL_DATA_PTR就是定义了一个要放在寄存器r8中的全局变量，名字叫gd，类型是一个指向gd_t类型变量的指针。

  为什么要定义为register？
  因为这个全局变量gd（global data的简称）是uboot中很重要的一个全局变量（准确的说这个全局变量是一个结构体，里面有很多内容，这些内容加起来构成的结构体就是uboot中常用的所有的全局变量），这个gd在程序中经常被访问，因此放在register中提升效率。因此纯粹是运行效率方面考虑，和功能要求无关。并不是必须的。

typedef	struct	global_data {
    
    
	bd_t		*bd;           //硬件相关的信息
	unsigned long	flags;     //标志位
	unsigned long	baudrate;  //通信的波特率（控制台的（（console））
	unsigned long	have_console;	/* serial_init() was called ，bool类型的变量，console：控制台，其是基于串口的，没有时，串口只能简单的工作，建立后串口即可printf，控制台是标准输入输出控制的*/
	unsigned long	reloc_off;	/* Relocation Offset ，重定位时的偏移量*/
	unsigned long	env_addr;	/* Address  of Environment struct，环境变量相关的地址 */
	unsigned long	env_valid;	/* Checksum of Environment valid?在内存的环境变量当前是否可以使用，是个bool类型变量，表明校验和是否成功 */
	unsigned long	fb_base;	/* base address of frame buffer ，缓存的起始地址*/
#ifdef CONFIG_VFD
	unsigned char	vfd_type;	/* display type */
#endif
#if 0
	unsigned long	cpu_clk;	/* CPU clock in Hz!		*/
	unsigned long	bus_clk;
	phys_size_t	ram_size;	/* RAM size */
	unsigned long	reset_status;	/* reset status register at boot */
#endif
	void		**jt;		/* jump table */
} gd_t;

  gd_t定义在include/asm-arm/global_data.h中。gd_t中定义了很多全局变量，都是整个uboot使用的；其中有一个bd_t类型的指针，指向一个bd_t类型的变量，这个bd是开发板的板级信息的结构体，里面有不少硬件相关的参数，譬如波特率、IP地址、机器码、DDR内存分布。

typedef struct bd_info {
    
    /*开发板的相关信息*/
    int			bi_baudrate;	/* serial console baudrate，硬件开发板的波特率 */
    unsigned long	bi_ip_addr;	/* IP Address开发板IP地址 */
    unsigned char	bi_enetaddr[6]; /* Ethernet adress，开发板网卡地址 */
    struct environment_s	       *bi_env;/*环境变量的指针*/
    ulong	        bi_arch_number;	/* unique id for this board，机器码 */
    ulong	        bi_boot_params;	/* where this board expects params，启动参数（uboot传递给内核的）的地址 */
    struct				/* RAM configuration */
    {
    
    
	ulong start;
	ulong size;
    }			bi_dram[CONFIG_NR_DRAM_BANKS];/*该结构体存储当前开发板的DDR的信息，DDR的配置*/
#ifdef CONFIG_HAS_ETH1
    /* second onboard ethernet port */
    unsigned char   bi_enet1addr[6];
#endif
} bd_t;

(1)DECLARE_GLOBAL_DATA_PTR只能 定义 了一个指针，也就是说gd里的这些全局变量并没
有被分配内存，我们在使用gd之前要给他分配内存，否则gd也只是一个野指针而已。

(2)gd和bd需要内存，内存当前没有被人管理（因为没有操作系统统一管理内存故而无法使用
malloc函数去申请内存，裸机程序也没有这个函数可以用），大片的DDR内存散放着可以随意
使用（只要使用内存地址直接去访问内存即可）。但是因为uboot中后续很多操作还需要大片
的连着内存块，因此这里使用内存要本着够用就好，紧凑排布的原则。所以我们在uboot中需
要有一个整体规划。

内存排布：
(1)uboot区	CFG_UBOOT_BASE-xx（长度为uboot的实际长度）
(2)堆区		长度为CFG_MALLOC_LEN，实际为912KB
(3)栈区		长度为CFG_STACK_SIZE，实际为512KB
(4)gd		长度为sizeof(gd_t)，实际36字节
(5)bd		长度为sizeof(bd_t)，实际为44字节左右
(6)内存间隔		为了防止高版本的gcc的优化造成错误。

普通内存使用是向上增的，gd->bd = (bd_t*)((char*)gd - sizeof(bd_t)); 

3、for循环执行init_sequence

(1)init_sequence是一个函数指针数组，数组中存储了很多个函数指针，这些指向指向的函数都是init_fnc_t类型（特征是接收参数是void类型，返回值是int）。

(2)init_sequence在定义时就同时给了初始化，初始化的函数指针都是一些函数名。（函数名的实质就是一个指针）

(3)init_fnc_ptr是一个二重函数指针，可以指向init_sequence这个函数指针数组。

(4)用for循环肯定是想要去遍历这个函数指针数组（遍历的目的也是去依次执行这个函数指针数组中的所有函数）。

  思考：如何遍历一个函数指针数组？
  有2种方法：第一种也是最常用的一种，用下标去遍历，用数组元素个数来截至。第二种不常用，但是也可以。就是在数组的有效元素末尾放一个标志，依次遍历到标准处即可截至（有点类似字符串的思路，字符串最后一位是\0）。

  我们这里使用了第二种思路。因为数组中存的全是函数指针，因此我们选用了NULL来作为标志。我们遍历时从开头依次进行，直到看到NULL标志截至。这种方法的优势是不用事先统计数组有多少个元素。

(5)init_fnc_t的这些函数的返回值定义方式一样的，都是：函数执行正确时返回0，不正确时返回-1。所以我们在遍历时去检查函数返回值，如果遍历中有一个函数返回值不等于0则hang()挂起。从分析hang函数可知：uboot启动过程中初始化板级硬件时不能出任何错误，只要有一个错误整个启动就终止，除了重启开发板没有任何办法。

(6)init_sequence中的这些函数，都是board级别的各种硬件初始化。

4、cpu_init、board_init

(1)cpu_init看名字这个函数应该是cpu内部的初始化，所以这里是空的。

(2)board_init在uboot/board/samsung/x210/x210.c中，这个看名字就知道是x210开发板相关的初始化。

int board_init(void)
{
    
    
	DECLARE_GLOBAL_DATA_PTR;
#ifdef CONFIG_DRIVER_SMC911X
	smc9115_pre_init();
#endif

#ifdef CONFIG_DRIVER_DM9000
	dm9000_pre_init();
#endif

	gd->bd->bi_arch_number = MACH_TYPE;
	gd->bd->bi_boot_params = (PHYS_SDRAM_1+0x100);

	return 0;
}

(3)DECLARE_GLOBAL_DATA_PTR 进行声明是为了后面使用gd方便。可以看出把gd的声明定义成一个宏的原因就是我们要到处去使用gd，因此就要到处声明，定义成宏比较方便。除了声明这种方法还可以使用头文件包含，不过涉及到路路径比较麻烦。不同版本的路径不同

(4)网卡初始化。CONFIG_DRIVER_DM9000这个宏是x210_sd.h中定义的，这个宏用来配置开发板的网卡的。dm9000_pre_in5it函数就是对应的DM9000网卡的初始化函数。开发板移植uboot时，如果要移植网卡，主要的工作就在这里。

(5)这个函数中主要是网卡的GPIO和端口的配置，而不是驱动。因为网卡的驱动都是现成的正确的，移植的时候驱动是不需要改动的，关键是这里的基本初始化。因为这些基本初始化是硬件相关的。

5、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官方，所以我们做好一个开发板并且移植了uboot之后，理论上应该提交给uboot官方审核并发放机器码（好像是免费的）。

  但是国内的开发板基本都没有申请（主要是因为国内开发者英文都不行，和国外开源社区接触比较少），都是自己随便编号的。随便编号的问题就是有可能和别人的编号冲突，但是只要保证uboot和kernel中的编号是一致的，就不影响自己的开发板启动。

6、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的其他地方使用内存时要注意，千万不敢把这里给淹没了。

背景：关于DDR的配置：
(1)board_init中除了网卡的初始化之外，剩下的2行用来初始化DDR。

(2)注意：这里的初始化DDR和汇编阶段lowlevel_init中初始化DDR是不同的。当时是硬件的
初始化，目的是让DDR可以开始工作。现在是软件结构中一些DDR相关的属性配置、地址设置的
初始化，是纯软件层面的。

(3)软件层次初始化DDR的原因：对于uboot来说，他怎么知道开发板上到底有几片DDR内存，
每一片的起始地址、长度这些信息呢？在uboot的设计中采用了一种简单直接有效的方式：
程序员在移植uboot到一个开发板时，程序员自己在x210_sd.h中使用宏定义去配置出来板子
上DDR内存的信息，然后uboot只要读取这些信息即可。（实际上还有另外一条思路：就是
uboot通过代码读取硬件信息来知道DDR配置，但是uboot没有这样。实际上PC的BIOS采用的
是这种）

(4)x210_sd.h的496行到501行中使用了标准的宏定义来配置DDR相关的参数。主要配置了
这么几个信息：有几片DDR内存、每一片DDR的起始地址、长度。这里的配置信息我们在
uboot代码中使用到内存时就可以从这里提取使用（uboot中使用到内存的地方都不是
直接用地址数字的，都是用宏定义的）

7、interrupt_init

(1)看名字函数是和中断初始化有关的，但是实际上不是，实际上这个函数是用来初始化定时器的（实际使用的是Timer4）。

(2)210共有5个PWM定时器。其中Timer0-timer3都有一个对应的PWM信号输出的引脚。而Timer4没有引脚，无法输出PWM波形。Timer4在设计的时候就不是用来输出PWM波形的（没有引脚，没有TCMPB寄存器），这个定时器被设计用来做计时。

(3)Timer4用来做计时时要使用到2个寄存器：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模式，然后开定时器开始计时就没了。

总结：在学习这个函数时，重点学会：通过定义结构体的方式来访问寄存器，通过函数来自动计算设置值以设置定时器。

8、env_init

(1)env_init，看名字就知道是和环境变量有关的初始化。

(2)为什么有很多env_init函数，主要原因是uboot支持各种不同的启动介质（譬如norflash、nandflash、inand、sd卡·····），我们一般从哪里启动就会把环境变量env放到哪里。

 &eemsp;而各种介质存取操作env的方法都是不一样的。因此uboot支持了各种不同介质中env的操作方法。所以有好多个env_xx开头的c文件。实际使用的是哪一个要根据自己开发板使用的存储介质来定（这些env_xx.c同时只有1个会起作用，其他是不能进去的，通过x210_sd.h中配置的宏来决定谁被包含的），对于x210来说，我们应该看env_movi.c中的函数。

(3)经过基本分析，这个函数只是对内存里维护的那一份uboot的env做了基本的初始化或者说是判定（判定里面有没有能用的环境变量）。当前因为我们还没进行环境变量从SD卡到DDR中的relocate，因此当前环境变量是不能用的。

(4)在start_armboot函数中（776行）调用env_relocate才进行环境变量从SD卡中到DDR中的重定位。重定位之后需要环境变量时才可以从DDR中去取，重定位之前如果要使用环境变量只能从SD卡中去读取。

9、init_baudrate

(1)init_baudrate看名字就是初始化串口通信的波特率的。

static int init_baudrate (void)
{
    
    
	char tmp[64];	/* long enough for environment variables */
	int i = getenv_r ("baudrate", tmp, sizeof (tmp));//返回值表示是否执行成功，一般返回0表示成功，
	gd->bd->bi_baudrate = gd->baudrate = (i > 0)//其他值（小于0，如-1）则发生错误，这里是返回的值大于0执行成功，小于0错误
			? (int) simple_strtoul (tmp, NULL, 10)
			: CONFIG_BAUDRATE;

	return (0);
}

(2)getenv_r函数用来读取环境变量的值。用getenv函数读取环境变量中“baudrate”的值（注意读取到的不是int型而是字符串类型），然后用simple_strtoul函数将字符串转成数字格式的波特率。

(3)baudrate初始化时的规则是：先去环境变量中读取"baudrate"这个环境变量的值。如果读取成功则使用这个值作为环境变量，记录在gd->baudrate和gd->bd->bi_baudrate中；如果读取不成功则使用x210_sd.h中的的CONFIG_BAUDRATE的值作为波特率。从这可以看出：环境变量的优先级是很高的。

10、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函数其实什么都没做（只有一个for循环，类似于延时）。因为在汇编阶段串口已经被初始化过了，因此这里就不再进行硬件寄存器的初始化了。

11、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而已，其他事情都没做。

12、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)但是在别的体系中，控制台的通信函数映射到硬件通信函数时可以用软件来做一些中间优化，譬如说缓冲机制。（操作系统中的控制台都使用了缓冲机制，所以有时候我们printf了内容但是屏幕上并没有看到输出信息，就是因为被缓冲了。我们输出的信息只是到了console的buffer中，buffer还没有被刷新到硬件输出设备上，尤其是在输出设备是LCD屏幕时）

(6)version_string这个字符串的组成部分：U_BOOT_VERSION在uboot源代码中找不到定义，这个变量实际上是在makefile中定义的，然后在编译时生成的include/version_autogenerated.h中用一个宏定义来实现的。

13、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)参考芯片的数据手册，比对这里调用的函数中计算各种时钟的方法，自己去慢慢分析体会这些代码的原理和实现方法。这就是学习。

14、checkboard、init_func_i2c、uboot学习实践

(1)checkboard看名字是检查、确认开发板的意思。这个函数的作用就是检查当前开发板是哪个开发板并且打印出开发板的名字。

(2)init_func_i2c这个函数实际没有被执行，X210的uboot中并没有使用I2C。如果将来我的开发板要扩展I2C来接外接硬件，则在x210_sd.h中配置相应的宏即可开启。

(3)uboot学习实践

(1)对uboot源代码进行完修改（修改内容根据自己的理解和分析来修改）
(2)make distclean然后make x210_sd_config然后make
(3)编译完成得到u-boot.bin，然后去烧录,具体烧录方式参考自己的开发板配套的烧录教程。
(4)总结：uboot就是个庞大点复杂点的裸机程序而已，我们完全可以对他进行调试。调试的
方法就是按照上面步骤，根据自己对代码的分析和理解对代码进行更改，然后重新编译烧录
运行，根据运行结果来学习。

15、dram_init

int dram_init(void)
{
    
    
	DECLARE_GLOBAL_DATA_PTR;

	gd->bd->bi_dram[0].start = PHYS_SDRAM_1;//第一片内存的起始地址
	gd->bd->bi_dram[0].size = PHYS_SDRAM_1_SIZE;//第一片内存的大小

#if defined(PHYS_SDRAM_2)
	gd->bd->bi_dram[1].start = PHYS_SDRAM_2;//第二片内存的起始地址
	gd->bd->bi_dram[1].size = PHYS_SDRAM_2_SIZE;//第二片内存的大小
#endif

#if defined(PHYS_SDRAM_3)
	gd->bd->bi_dram[2].start = PHYS_SDRAM_3;
	gd->bd->bi_dram[2].size = PHYS_SDRAM_3_SIZE;
#endif

	return 0;
}

(1)dram_init看名字是关于DDR的初始化。疑问：在汇编阶段已经初始化过DDR了否则也无法relocate到第二部分运行，怎么在这里又初始化DDR？

(2)dram_init都是在给gd->bd里面关于DDR配置部分的全局变量赋值，让gd->bd数据记录下当前开发板的DDR的配置信息，以便uboot中使用内存。

(3)从代码来看，其实就是初始化gd->bd->bi_dram这个结构体数组。

16、display_dram_config

static int display_dram_config (void)
{
    
    
	int i;

#ifdef DEBUG//文件开头处定义了:#undef DEBUG,故而执行else下的语句
	puts ("RAM Configuration:\n");

	for(i=0; i<CONFIG_NR_DRAM_BANKS; i++) {
    
    
		printf ("Bank #%d: %08lx ", i, gd->bd->bi_dram[i].start);
		print_size (gd->bd->bi_dram[i].size, "\n");
	}
#else
	ulong size = 0;

	for (i=0; i<CONFIG_NR_DRAM_BANKS; i++) {
    
    
		size += gd->bd->bi_dram[i].size;
	}

	puts("DRAM:    ");
	print_size(size, "\n");
#endif

	return (0);
}

(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

(4)init_sequence总结：都是板级硬件的初始化以及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总容量。

17、回到start_armboot函数，CFG_NO_FLASH

(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，实际没用之外也没有别的影响）三星官方开发板是有norflash的，我买的国内厂商的开发板为了节约成本，所以没有

(3)代码实践，去掉Flash看会不会出错。

  结论：加上CONFIG_NOFLASH宏之后编译出错，说明代码移植的不好，那个文件的包含没有被这个宏控制。于是乎移植的人就直接放这没管。

  CONFIG_VFD 和 CONFIG_LCD是显示相关的，这个是uboot中自带的LCD显示的软件架构。但是实际上我们用LCD而没有使用uboot中设置的这套软件架构，我们自己在后面自己添加了一个LCD显示的部分。

18、mem_malloc_init

(1)mem_malloc_init函数用来初始化uboot的堆管理器。（告诉堆管理器你管理的这段内存从哪开始到哪结束）

static void mem_malloc_init (ulong dest_addr)
{
    
    
	mem_malloc_start = dest_addr;
	mem_malloc_end = dest_addr + CFG_MALLOC_LEN;
	mem_malloc_brk = mem_malloc_start;

	memset ((void *) mem_malloc_start, 0,
			mem_malloc_end - mem_malloc_start);//将堆内存清零
}

(2)uboot中自己维护了一段堆内存，肯定自己就有一套代码来管理这个堆内存。有了这些东西uboot中你也可以malloc、free这套机制（并非操作系统独有，有了堆管理器uboot也可以，堆管理器其实也是一堆代码，实质就是移植了malloc函数，真正维护了一段内存）来申请内存和释放内存。上边我们讲到过在DDR内存中给堆预留了896KB的内存。

19、开发板独有初始化：mmc初始化

补充学习：
https://jingyan.baidu.com/article/03b2f78cd810115ea237ae2d.html

(1)start_armboot函数从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内核中移植过来的各种驱动源文件。本来裸机是无法使用linux驱动的，uboot做了相应的移
植。

(5)mmc_initialize是具体硬件架构无关的一个MMC初始化函数，所有的使用了这套架构的代码都掉用这个函数来完成MMC的初始化。

  mmc_initialize中再调用board_mmc_init和cpu_mmc_init来完成具体的硬件的MMC控制器初始化工作。(我们在硬件初始化一个SD卡控制器时，我们先考虑开发板这个层次，若这个层次初始化成功，表明SD卡控制器是开发板这个层面的，集成或者外接扩展的SD卡控制器芯片，这种情况下的初始化应在board_mmc_init中完成，但210芯片内部本身内置了SD卡控制器，所以在cpu_mmc_init完成MMC的初始化,所以有两个层次，有一个层次工作就行了。这里是cpu_mmc_init工作)

(6)cpu_mmc_init在uboot/cpu/s5pc11x/cpu.c中，这里面又间接的调用了drivers/mmc/s3c_mmcxxx.c中的驱动代码来初始化硬件MMC控制器。这里面分层很多，分层的思想一定要有，否则完全就糊涂了。

summary:初始化MMC控制器其实在irom已经做过了，因为SD卡启动时要读取BL1，这里再次初始化，是因为irom内部的初始化比较简单，外部的这个比较完善，完整，还涉及到初始化外部SD卡设备等

20、env_relocate

(1)env_relocate是环境变量的重定位，完成从SD卡中将环境变量读取到DDR中的任务。

(2)环境变量到底从哪里来？

  SD卡中有一些独立的扇区作为环境变量存储区域的。但是我们烧录/部署系统时，我们只是烧录了uboot分区、kernel分区和rootfs分区，根本不曾烧录env分区。所以当我们烧录完系统第一次启动时ENV分区是空的，本次启动uboot尝试去SD卡的ENV分区读取环境变量时失败（读取回来后进行CRC校验时失败），我们uboot选择从uboot内部代码中设置的一套默认的环境变量出发来使用（这就是默认环境变量）；

  这套默认的环境变量在本次运行时会被读取到DDR中的环境变量中，然后被写入（也可能是你saveenv时写入，也可能是uboot设计了第一次读取默认环境变量后就写入）SD卡的ENV分区。然后下次再次开机时uboot就会从SD卡的ENV分区读取环境变量到DDR中，这次读取就不会失败了。（因为上次保存时保存了CRC，所以这次校验不会出错）

(3)真正的从SD卡到DDR中重定位ENV的代码是在env_relocate_spec内部的movi_read_env完成的。

void env_relocate (void)
{
    
    
	DEBUGF ("%s[%d] offset = 0x%lx\n", __FUNCTION__,__LINE__,
		gd->reloc_off);

#ifdef CONFIG_AMIGAONEG3SE
	enable_nvram();
#endif

#ifdef ENV_IS_EMBEDDED//环境变量是内嵌到设备里边的，这个在这里是没有被定义的，通过查找
	/*
	 * The environment buffer is embedded with the text segment,
	 * just relocate the environment pointer
	 */
	env_ptr = (env_t *)((ulong)env_ptr + gd->reloc_off);//环境变量相对于代码段首地址的偏移量：gd->reloc_off
	DEBUGF ("%s[%d] embedded ENV at %p\n", __FUNCTION__,__LINE__,env_ptr);
#else
	/*
	 * We must allocate a buffer for the environment
	 */
	env_ptr = (env_t *)malloc (CFG_ENV_SIZE);//之前初始化了堆管理器，故而这里可以使用malloc函数了
	DEBUGF ("%s[%d] malloced ENV at %p\n", __FUNCTION__,__LINE__,env_ptr);
#endif

	if (gd->env_valid == 0) {
    
    //表明校验和失败
#if defined(CONFIG_GTH)	|| defined(CFG_ENV_IS_NOWHERE)	/* Environment not changable */
		puts ("Using default environment\n\n");
#else//这次执行的是else下的
		puts ("*** Warning - bad CRC, using default environment\n\n");
		show_boot_progress (-60);//uboot启动的程度，到了%多少
#endif
		set_default_env();
	}
	else {
    
    
		env_relocate_spec ();//完成从SD卡到DDR的重定位
	}
	gd->env_addr = (ulong)&(env_ptr->data);//malloc申请的那段内存的首地址

#ifdef CONFIG_AMIGAONEG3SE
	disable_nvram();
#endif
}

21、IP地址、MAC地址的确定

(1)开发板的IP地址是在gd->bd中维护的，来源于环境变量ipaddr。getenv函数用来获取字符串格式的IP地址，然后用string_to_ip将字符串格式的IP地址转成字符串格式的点分十进制格式。

(2)IP地址由4个0-255之间的数字组成，因此一个IP地址在程序中最简单的存储方法就是一个unsigend int。但是人类容易看懂的并不是这种类型，而是点分十进制类型（192.168.1.2）。这两种类型可以互相转换。

22、devices_init

(1)devices_init看名字就是设备的初始化。这里的设备指的就是开发板上的硬件设备。（之前已经初始化过一些设备了，这里是剩下的还未被初始化的）这里初始化的设备都是驱动设备，这个函数本来就是从驱动框架中衍生出来的。

  uboot中很多设备的驱动是直接移植linux内核的（譬如网卡、SD卡），linux内核中的驱动都有相应的设备初始化函数。linux内核在启动过程中就有一个devices_init(名字不一定完全对，但是差不多)，作用就是集中执行各种硬件驱动的init函数。

(2)uboot的这个函数其实就是从linux内核中移植过来的，它的作用也是去执行所有的从linux内核中继承来的那些硬件驱动的初始化函数。

23、jumptable_init

(1)jumptable跳转表，本身是一个函数指针数组，里面记录了很多函数的函数名。实现一个函数指针到具体函数的映射关系，将来通过跳转表中的函数指针就可以执行具体的函数。这个其实就是在用C语言实现面向对象编程。在linux内核中有很多这种技巧。

(2)通过分析发现跳转表只是被赋值从未被引用，因此跳转表在uboot中根本就没使用。

24、console_init_r

(1)console_init_f是控制台的第一阶段初始化，console_init_r是第二阶段初始化。实际上第一阶段初始化并没有实质性工作，第二阶段初始化才进行了实质性工作。

(2)uboot中有很多同名函数，使用SI（即SourceInsight）工具去索引时经常索引到不对的函数处（回忆下当时start.S中找lowlevel_init.S时，自动索引找到的是错误的，真正的反而根本没找到。）有时候只找到一个也不一定只有一个，要去搜索确认。找到的这个不一定是对的。

  注意文件名是否与自己所要的相对应或者有关联。有时候有些宏虽然定义了，但是在我们不使用的文件中，所以要注意。有时候虽然也在我们使用的文件中编译了，但这个宏可能在另一个条件编译中，在这个条件编译中未编译。

(3)console_init_r就是console的纯软件架构方面的初始化（说白了就是去给console相关的数据结构中填充相应的值），所以属于纯软件配置类型的初始化。

(4)uboot的console实际上并没有干有意义的转化，它就是直接调用的串口通信的函数。所以用不用console实际并没有什么分别。（在linux内console就可以提供缓冲机制等不用console不能实现的东西）。

25、enable_interrupts

  通过SI工具搜索，有多个，有空的也有实际功能的，有空的是为了满足某些代码的要求，使得编译不报错，但由于实际并不需要这个功能所以设为了空。除了设置空的函数还可以通过使用条件编译使用宏，让某些代码不包含它或者选择包含空的，这样编译就不会报错了。

(1)看名字应该是中断初始化代码。这里指的是CPSR中总中断标志位的使能。

(2)因为我们uboot中没有使用中断，因此没有定义CONFIG_USE_IRQ宏，因此我们这里这个函数是个空壳子。

(3)uboot中经常出现一种情况就是根据一个宏是否定义了来条件编译决定是否调用一个函数内部的代码。

  uboot中有2种解决方案来处理这种情况：方案一：在调用函数处使用条件编译，然后函数体实际完全提供代码。方案二：在调用函数处直接调用，然后在函数体处提供2个函数体，一个是有实体的一个是空壳子，用宏定义条件编译来决定实际编译时编译哪个函数进去。

26、loadaddr、bootfile环境变量、board_late_init函数

(1)这两个环境变量都是内核启动有关的，在启动linux内核时会参考这两个环境变量的值。

(2)看名字这个函数就是开发板级别的一些初始化里比较晚的了，就是晚期初始化。所以晚期就是前面该初始化的都初始化过了，剩下的一些必须放在后面初始化的就在这里了。侧面说明了开发板级别的硬件软件初始化告一段落了。

(3)对于X210来说，这个函数是空的。

27、eth_initialize、x210_preboot_init（LCD和logo显示）

(1)看名字应该是网卡相关的初始化。这里不是SoC与网卡芯片连接时SoC这边的初始化，而是网卡芯片本身的一些初始化。

(2)对于X210（DM9000）来说，这个函数是空的。X210的网卡初始化在board_init函数中，网卡芯片的初始化在驱动中。

(3)x210开发板在启动起来之前的一些显示相关的初始化，以及LCD屏幕上的logo显示。该函数在/board/samsung/x210/x210.c

28、check menukey to update from sd

(1)uboot启动的最后阶段设计了一个自动更新的功能。就是：我们可以将要升级的镜像放到SD卡的固定目录中，然后开机时在uboot启动的最后阶段检查升级标志（是一个按键。按键中标志为"LEFT"的那个按键，这个按键如果按下则表示update mode，如果启动时未按下则表示boot mode）。

  如果进入update mode则uboot会自动从SD卡中读取镜像文件然后烧录到iNand中；如果进入boot mode则uboot不执行update，直接启动正常运行。

(2)这种机制能够帮助我们快速烧录系统，常用于量产时用SD卡进行系统烧录部署。

29、死循环uboot/common/main.c的main_loop函数

(1)解析器

(2)开机倒数自动执行

(3)命令补全（有这个函数但没用，所以没这个功能，通过使用这个函数也可以有）

/****************************************************************************/

void main_loop (void)
{
    
    
#ifndef CFG_HUSH_PARSER      
	static char lastcommand[CFG_CBSIZE] = {
    
     0, };
	int len;
	int rc = 1;
	int flag;
#endif

#if defined(CONFIG_BOOTDELAY) && (CONFIG_BOOTDELAY >= 0)//自动倒数执行相关
	char *s;
	int bootdelay;
#endif

#ifdef CONFIG_PREBOOT
	char *p;
#endif

#ifdef CONFIG_BOOTCOUNT_LIMIT
	unsigned long bootcount = 0;
	unsigned long bootlimit = 0;
	char *bcs;
	char bcs_set[16];
#endif /* CONFIG_BOOTCOUNT_LIMIT */

#if defined(CONFIG_VFD) && defined(VFD_TEST_LOGO)
	ulong bmp = 0;		/* default bitmap */
	extern int trab_vfd (ulong bitmap);

	#ifdef CONFIG_MODEM_SUPPORT
	if (do_mdm_init)
		bmp = 1;	/* alternate bitmap */
	#endif
	trab_vfd (bmp);
#endif	/* CONFIG_VFD && VFD_TEST_LOGO */

#ifdef CONFIG_BOOTCOUNT_LIMIT
	bootcount = bootcount_load();
	bootcount++;
	bootcount_store (bootcount);
	sprintf (bcs_set, "%lu", bootcount);
	setenv ("bootcount", bcs_set);
	bcs = getenv ("bootlimit");
	bootlimit = bcs ? simple_strtoul (bcs, NULL, 10) : 0;
#endif /* CONFIG_BOOTCOUNT_LIMIT */

#ifdef CONFIG_MODEM_SUPPORT
	debug ("DEBUG: main_loop:   do_mdm_init=%d\n", do_mdm_init);
	if (do_mdm_init) {
    
    
		char *str = strdup(getenv("mdm_cmd"));
		setenv ("preboot", str);  /* set or delete definition */
		if (str != NULL)
			free (str);
		mdm_init(); /* wait for modem connection */
	}
#endif  /* CONFIG_MODEM_SUPPORT */

#ifdef CONFIG_VERSION_VARIABLE
	{
    
    
		extern char version_string[];

		setenv ("ver", version_string);  /* set version variable */
	}
#endif /* CONFIG_VERSION_VARIABLE */

#ifdef CFG_HUSH_PARSER     //PARSER 解析器
	u_boot_hush_start ();
#endif

#ifdef CONFIG_AUTO_COMPLETE//命令自动补全
	install_auto_complete();
#endif

#ifdef CONFIG_FASTBOOT//不要去屏蔽掉 CONFIG_FASTBOOT，否则fastboot 功能也会被屏蔽掉
    if (fastboot_preboot())//决定是否自动进入fastboot烧写模式
        run_command("fastboot", 0);//不想自动进入修改或屏蔽345-346代码即可
#endif

#ifdef CONFIG_PREBOOT
	if ((p = getenv ("preboot")) != NULL) {
    
    
	#ifdef CONFIG_AUTOBOOT_KEYED
		int prev = disable_ctrlc(1);	/* disable Control C checking */
	#endif

	#ifndef CFG_HUSH_PARSER
		run_command (p, 0);//执行命令的函数
	#else
		parse_string_outer(p, FLAG_PARSE_SEMICOLON |
				    FLAG_EXIT_FROM_LOOP);//解析字符串
	#endif

	#ifdef CONFIG_AUTOBOOT_KEYED
		disable_ctrlc(prev);	/* restore Control C checking */
	#endif
	}
#endif /* CONFIG_PREBOOT */

#if defined(CONFIG_BOOTDELAY) && (CONFIG_BOOTDELAY >= 0)
	s = getenv ("bootdelay");
	bootdelay = s ? (int)simple_strtol(s, NULL, 10) : CONFIG_BOOTDELAY;

	debug ("### main_loop entered: bootdelay=%d\n\n", bootdelay);

# ifdef CONFIG_BOOT_RETRY_TIME
	init_cmd_timeout ();
# endif	/* CONFIG_BOOT_RETRY_TIME */

#ifdef CONFIG_POST
	if (gd->flags & GD_FLG_POSTFAIL) {
    
    
		s = getenv("failbootcmd");
	}
	else
#endif /* CONFIG_POST */

#ifdef CONFIG_BOOTCOUNT_LIMIT
	if (bootlimit && (bootcount > bootlimit)) {
    
    
		printf ("Warning: Bootlimit (%u) exceeded. Using altbootcmd.\n",
		        (unsigned)bootlimit);
		s = getenv ("altbootcmd");
	}
	else
#endif /* CONFIG_BOOTCOUNT_LIMIT */
		s = getenv ("bootcmd");

	debug ("### main_loop: bootcmd=\"%s\"\n", s ? s : "<UNDEFINED>");

	if (bootdelay >= 0 && s && !abortboot (bootdelay)) {
    
    
#ifdef CONFIG_AUTOBOOT_KEYED
		int prev = disable_ctrlc(1);	/* disable Control C checking */
#endif

#ifndef CFG_HUSH_PARSER
		run_command (s, 0);
#else
		parse_string_outer(s, FLAG_PARSE_SEMICOLON |
				    FLAG_EXIT_FROM_LOOP);//解析字符串
#endif

#ifdef CONFIG_AUTOBOOT_KEYED
		disable_ctrlc(prev);	/* restore Control C checking */
#endif
	}

#ifdef CONFIG_MENUKEY
	if (menukey == CONFIG_MENUKEY) {
    
    
	    s = getenv("menucmd");
	    if (s) {
    
    
#ifndef CFG_HUSH_PARSER
		run_command (s, 0);
#else
		parse_string_outer(s, FLAG_PARSE_SEMICOLON |
				    FLAG_EXIT_FROM_LOOP);
#endif
	    }
	}
#endif /* CONFIG_MENUKEY */
#endif	/* CONFIG_BOOTDELAY */

#ifdef CONFIG_AMIGAONEG3SE
	{
    
    
	    extern void video_banner(void);
	    video_banner();
	}
#endif

	/*
	 * Main Loop for Monitor Command Processing
	 */
#ifdef CFG_HUSH_PARSER
	parse_file_outer();
	/* This point is never reached */
	for (;;);
#else
	for (;;) {
    
    
	#ifdef CONFIG_BOOT_RETRY_TIME
		if (rc >= 0) {
    
    
			/* Saw enough of a valid command to
			 * restart the timeout.
			 */
			reset_cmd_timeout();
		}
	#endif
		len = readline (CFG_PROMPT);

		flag = 0;	/* assume no special flags for now */
		if (len > 0)
			strcpy (lastcommand, console_buffer);
		else if (len == 0)
			flag |= CMD_FLAG_REPEAT;
#ifdef CONFIG_BOOT_RETRY_TIME
		else if (len == -2) {
    
    
			/* -2 means timed out, retry autoboot
			 */
			puts ("\nTimed out waiting for command\n");

	#ifdef CONFIG_RESET_TO_RETRY
			/* Reinit board to run initialization code again */
			do_reset (NULL, 0, 0, NULL);
	#else
			return;		/* retry autoboot */
	#endif
		}
#endif

		if (len == -1)
			puts ("<INTERRUPT>\n");
		else
			rc = run_command (lastcommand, flag);

		if (rc <= 0) {
    
    
			/* invalid command or not repeatable, forget it */
			lastcommand[0] = 0;
		}
	}
#endif /*CFG_HUSH_PARSER*/
}

三、uboot启动第2阶段总结

1、启动流程回顾、重点函数标出

(1)第二阶段主要是对开发板级别的硬件、软件数据结构进行初始化。

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			主循环

2、启动过程特征总结

(1)第一阶段为汇编阶段（通用性很强，不同开发板CPU很多都是共用的，一般CPU原厂都会调好，使用jtag这类的工具）、第二阶段为C阶段（这是我们移植主要看的部分）

(2)第一阶段在SRAM中、第二阶段在DRAM中

(3)第一阶段注重SoC内部、第二阶段注重SoC外部Board内部

3、移植时的注意点

(1)x210_sd.h头文件中的宏定义

(2)特定硬件的初始化函数位置（譬如网卡），清楚整个过程，才能在发生错误的时候精准定位，快速修改。

注：本资料大部分由朱老师物联网大讲堂课程笔记整理而来、引用了百度百科、部分他人博客的内容并结合自己实际开发经历，如有侵权，联系删除！水平有限，如有错误，欢迎各位在评论区交流。