1.官方原版uboot的版本
1)版本号。刚开始是1.3.4，后来变成2009.08
2)新版和旧版的差别。uboot的架构很早就定下来了，然后里面普遍公用的东西（common目录下、drivers目录下、fs目录下等•••）在各个版本之间几乎是完全一样的。差别最大的是board和cpu目录，这两个目录正是单板（开发板）相关的。越新的uboot版本支持越多的开发板（CPU），所以越新的uboot越庞大。
3)并不是越新的版本就越好。越新的uboot中会多出更多的开发板的支持代码，如果我们的开发板并不是很新，就没必要去用很新版本的uboot。因为多出来的代码自己也用不到而且还会成为累赘。
2.官方原版uboot的来源
1)从uboot官方网站ftp下载
2)从一些镜像网站下载
2.1新版uboot配置体系的改变
1)在最新的uboot版本（准确的说是2013.10到2014.10中的某个版本）中，uboot的文件体系发生了一个很大的变化。这个变化就是uboot引入了linux kernel的配置体系（Kbuild、Kconfig、menuconfig），从而让我们可以在图形界面下，像配置内核一样配置uboot。
2)所以新版本的uboot配置时和我们之前的课程讲的就不同了。我们移植时不能选择这种配置方式更改之后的uboot版本。我们要选择更改之前的。
3)新版本的配置方式本质上和linux kernel一样的，所以在学完linux kernel移植后自己就能看懂，因此不用担心。
2.2结论：选择合适的官方原版uboot进行移植
结合以上，选择2013.10版本进行实验移植是比较合理的。注意：实践工作中一般是从SoC厂商的uboot出发移植的
在工作中一般是不需要从uboot官方版本出发去做移植的，而是从SoC厂商提供的开发板配套的uboot去做移植的。
2.3文件夹结构浏览
1)文件夹结构分析、主要文件检视
总的来说，文件夹结构和以前基本一样。不同的主要是lib，以前是lib_arm和lib_generic，现在是arch和lib。arch目录下放的是和cpu架构有关的东西。
总的来说，2013.10版本的uboot在结构上和1.3.4版本的uboot还是有所不同的。
2)参照物开发板的选择
我们开发板使用的CPU是S5PV210，所以要找uboot中针对S5PV210或者S5PC110进行移植的作为参考。根据规律，我们应该参考include/configs/s5p_goni.h，对应的board在uboot/board/samsung/goni这个目录。
2.4主Makefile浏览及boards.cfg文件
1)2013.10版本的uboot的Makefile中使用了boards.cfg文件，因此在配置uboot时make xxx_config，这个xxx要到boards.cfg文件中查找。
2)其实就相当于把以前的版本的uboot中各种开发板的配置部分规则抽离出来写到了Makefile中，然后把配置信息部分写到了一个独立文件boards.cfg。
2.5结论：
1)参照物开发板为：55p_goni
2)配置对应的cpu、board文件夹分别为：
cpu: u-boot-2013.10\arch\arm\cpu\armv7
board: u-boot-2013.10\board\samsung\goni
3.脚本功能浏览
1)首先我们在命令行配置uboot时，是：make s5p_goni_config，对应Makefile中的一个目标。
2)新版本的Makefile中：
%_config:: unconfig
@$(MKCONFIG) -A $(@:_config=)
这里的规则用了双冒号 ::
双冒号规则中，当依赖文件比目标更新时。规则将会被执行。对于一个没有依赖而只有命令行的双冒号规则，当引用此目标时，规则的命令将会被无条件执行。而普通规则，当规则的目标文件存在时，此规则的命令永远不会被执行（目标文件永远是最新的）。
$(@:_config=)：请看Gnu Make中文手册5.3.1 变量的替换引用。
$(@)代表目标s5p_goni _config，$(@:_config=)：表示用等号后面的内容替代掉:和=之间的内容，=后面为空，那么_config就等于被删去了，$(@:_config=)就代表s5p_goni
./mkconfig -A $(@:_config=)
从这里分析得出结论，实际配置时是调用mkconfig脚本，然后传参2个：-A和s5p_goni
###### $#表示传入参数个数，由上可知$# = 2，符合条件。 -a表示逻辑与。$1表示第一个参数，等于-A，符合条件，所以then后面的语句被执行。
这段代码符号比较多，看起来比较复杂，请百度shell 符号，你会有所收获。
line=`awk**************`
用倒引号``把命令的输出作为字串，如果是""，则里面的内容不被当做命令执行，而是当做纯粹的字符串，但可引用变量' '单引号内的内容作为字串，但变量$符号不会起作用（忽略任何引用），
单括号()内可以的内容可以执行命令，也就是说，()内先执行，再用''把()的输出当做纯字串，大括号同理。
//斜杠表示里面的内容是正则表达式。
($0 !~ /^#/ && $7 ~ /^'"$2"'$/)
在awk命令里，$不是shell变量符号，而是域标记。但是也有例外：双引号""中的$可以引用变量（参见《LINUX与UNIX SHELL编程指南》67页，9.2.2节，"域和记录"和第15章，引号），所以这里的$7 为boards.cfg里的域7，而$2则表示mkconfig的第二个参数，没错，就是s5p_goni，/^'"$2"'$/表示只包含变量$2的行，依然是s5p_goni。
$0表示所有域，$0 !~ /^#/ 意思是，awk排除以#开头的行，这句话用来排除那些以#开头的注释内容。$7 ~ /^'"$2"'$/表示记录的域7必须为s5p_goni。
boards.cfg只有下面这行符合条件：
Active arm armv7 s5pc1xx samsung goni s5p_gonib -
然后执行{ print $1, $2, $3, $4, $5, $6, $7, $8 }
这样line就等于Active arm armv7 s5pc1xx samsung goni s5p_goni -
接下来：
set ${line}
# add default board name if needed
[ $# = 3 ] && set ${line} ${1}
set命令
参见《高级bash脚本编程指南》202页
set 命令用来修改内部脚本变量的值.一个作用就是触发选项标志位来帮助决定脚本的行
为.另一个应用就是以一个命令的结果(set `command`)来重新设置脚本的位置参数.脚本
将会从命令的输出中重新分析出位置参数。
所以mkconfig 的位置参数被重新定义为$(line)的内容，即：
$1=Active $2=arm $3=armv7 $4=s5pc1xx $5=samsung $6=smdkc100 $7= s5p_goni $8=-（注意是短破折号，不是空格）
补充一下，以上排列为：
# Status, Arch, CPU:SPLCPU, SoC, Vendor, Board name, Target, Options
对于[ $# = 3 ] && set ${line} ${1}：
&&的说明参见《LINUX与UNIX SHELL编程指南》6.1 使用&&
这里先判断$# 是否等于 3（明显不等），相等则执行&&右边的命令。那么，直接跳过吧。
3)到了mkconfig脚本中了。在24到35行中使用awk正则表达式将boards.cfg中与刚才$1（s5p_goni）能够匹配上的那一行截取出来赋值给变量line，然后将line的内容以空格为间隔依次分开，分别赋值给$1、$2•••$8。
4)注意在解析完boards.cfg之后，$1到$8就有了新的值。
$1 = Active
$2 = arm
$3 = armv7
$4 = s5pc1xx
$5 = samsung
$6 = goni
$7 = s5p_goni
$8 = -
4.几个传参和其含义
几个很重要的变量
arch=arm
cpu=armv7
vendor=samsung
soc=s5pc1xx
5.符号链接
1)include/asm -> arch/arm/include/asm
2)include/asm/arch -> include/asm/arch-s5pc1xx
3)include/asm/proc -> include/asm/proc-armv
最后创建了include/config.h文件。
6.Makefile中添加交叉编译工具链
1)官方原版的uboot中CROSS_COMPLIE是没有定义的，需要自己去定义。如果没定义就直接去编译，就会用gcc编译。
2)添加一行：
CROSS_COMPILE = /usr/local/arm/arm-2009q3/bin/arm-none-linux-gnueabi-
7.配置编译测试
1)编译过程：
make distclean
make s5p_goni_config
make
2)结果：得到u-boot.bin即可
8.分析：为什么烧录运行不正确？
1)串口接串口2，串口有输出。但是这个串口输出不是uboot输出的，而是内部iROM中的BL0运行时输出的。
2)输出错误信息分析：
第一个SD checksum Error：是第一顺序启动设备SD0（iNand）启动时校验和失败打印出来的；
第二个SD checksum Error：是第二顺序启动设备SD2（外部SD卡）启动时校验和失败打印出来的；
剩下的是串口启动和usb启动的东西，可以不管。
总结：从两个SD checksum Error，可以看出：外部SD卡校验和失败了。
分析：SD卡烧录出错了，导致SD卡校验和会失败。
9.解决方案分析
1)为什么SD卡烧录会出错？可能原因：烧录方法错误、烧录原材料错误。
2)经过分析，sd_fusing这个文件夹下的mkbl1这个程序肯定没错，上一层目录下的u-boot.bin是存在的，校验和失败不失败和u-boot.bin无关。
3)经过分析和查找，发现是mkbl1程序和start.S中前16个字节校验和的处理上面不匹配造成的，解决方法是在start.S最前面加上16个字节的占位。
10.代码实践
重新编译烧录运行，发现结果只显示一个SD checksum Error。这一个就是内部SD0通道的inand启动校验和失败打印出来的。剩下的没有了说明外部SD卡校验和成功了，只是SD卡上的uboot是错误的，没有串口输出内容，所以没有输出了。