一、uboot的配置和编译过程
uboot配置和编译过程详解
uboot下include\autoconfig.mk分析
(转)autoconfig.mk文件的自动生成
一、Makefile
1)Makefile中make xxx_config ——传参(ARCH、CPU、BOARD、VENDOR、SOC)——> mkconfig,该脚本中主要做了如下几件事情:生成对应的符号链接,用于后续头文件包含;生成CONFIG_NAME变量(其实就是xxx_config),用于包含configs/xxx_config.h;生成include/config.h,包含了传参的内容,顶层Makefile就是利用这个头文件制作autoconf.mk的。
2)Makefile加载顶层config.mk,该文件中主要做了:包含子文件夹下的config.mk;确定链接地址CONFIG_SYS_TEXT_BASE;确定链接脚本u-boot.lds;
3)配置时Makefile中的生成autoconf.mk文件,里面全都是CONFIG_开头的宏,用于指导整个uboot编译;
二、链接脚本
1)_ENTRY(start) 指定程序入口;
2)指定链接地址,但是Makefile配置时会重新指定链接地址,因此此处会被覆盖失效;
3).text 代码段、.bss BSS段等;
二、uboot的烧录镜像(制作镜像)
sd_fdisk用于SD卡分区;——》
mkbl1计算uboot校验和,写入开头位置,然后截取前8K生成BL1;——》
sd_fusing.sh烧录脚本,用于调用上述两个可执行文件,并使用dd命令烧录BL1(扇区1)和BL2(整个uboot,扇区49)。
注:校验和计算方法、校验和写入到前16字节预留中的第8字节(且第1个字节存放BL1的长度)、BL1放在SD卡第1个扇区(第0扇区存放着mmc分区信息),这些都是S5PV210芯片规定的,其他芯片不一定是这样的。
三、uboot的第一阶段(BL1/汇编阶段/start.S)中做了哪些工作
uboot启动分析第一阶段(start.S)
start.s之lowlevel_init分析
u-boot第一阶段start.s分析:lowlevel_init部分
uboot之启动文件start.S的分析
一、start.S中:
1)构建异常向量表;
2)关中断,设置SVC模式;
3)设置CP15寄存器,与mmu、cache、TLB相关
4)调用lowlevel_init
5)远跳转,进入BL2
二、lowlevel_init中:至少要完成的1)DDR初始化;2)重定位;
3)关看门狗、开发板供电锁存;
4)时钟初始化;
5)串口初始化;
四、如何运行到uboot第二阶段
使用ldr pc, _start_armboot
跳转到uboot第二阶段,_start_armboot是一个C函数。ldr pc是一句远跳转指令,可以直接从iRAM中运行的代码直接跳转到DDR中的这个函数。
五、uboot第二阶段做了哪些工作
六、uboot的目录结构
七、uboot的mmu映射
八、uboot第二阶段的gd、bd全局变量
U-BOOT之五:gd_t和bd_t数据结构简介
uboot引导kernel - 4 ->gd bd详解
uboot中gd_t和bd_t数据结构简介
作用:在各硬件初始化阶段中,通过这两个数据结构来保存或传递数据的。最终启动内核时,给传参也是通过这2个全局变量传递,例如:bd->bi_boot_params、bd->bi_dram、等。
bd:主要保存板子参数
bi_baudrate; 波特率
bi_arch_number; 开发板ID(机器码)
bi_boot_params; u-boot传递给内核的参数的保存地址
bi_dram[CONFIG_NR_DRAM_BANKS]; DDR内存块,每块包含起始地址和size
gd:主要是一些全局的系统初始化参数
包含bd;
env相关的;
其他。。。
九、uboot使用Kconfig配置
我的理解:替代了原先mkconfig的配置过程,其实就是将"ARCH CPU BOARD VENDOR SOC"这些个参数进行图形化界面选择,再配置。
十、uboot中的iROM、iRAM、SROM、SRAM
soc中的iROM(是否为SROM不确定?)执行固化代码,将前8K启动代码从外部存储器中(OM引脚选择)拷贝到内部的iRAM(SRAM)中运行。
十一、uboot如何启动内核
Uboot到底如何启动内核
(六) u-boot 启动内核解析
嵌入式之uboot如何启动内核学习笔记
九.linux开发之uboot移植(九)——uboot源码分析3-uboot启动内核机制
1、调用一个叫 theKernel 或 kernel_entry 的函数指针。名称无无所谓,其值来源于image全局变量的image.ep,而ep来源于通过调用image_get_ep (&images->legacy_hdr_os_copy);
,images->legacy_hdr_os_copy又是通过memmove (&images.legacy_hdr_os_copy, hdr, sizeof(image_header_t));
拷贝得来的,而hdr就是bootm带的参数;
2、期间还回去检验内核格式(uImage还是fit?)和crc等;
3、启动内核时传参,第一个参数固定传0(放在r0寄存器),第二个参数传machid机器码(放在r1寄存器),第三个参数传bi_boot_params TAG传参地址(放在r2寄存器);
十二、uboot的命令体系
uboot的命令体系
uboot命令体系
uboot的命令体系
uboot没有将命令集实现为数组或链表。
数组不够灵活,定义大了浪费空间,定义小了,加命令是担心越界。链表虽然灵活,但是会有查找的开销、以及编码难度的上升,最重要的是命令不需要程序运行时去动态添加或删除命令,所以用链表又有点过了。
uboot的命令集存放实现为放在一个用户自定义段中,该段是在链接时将带有相同段属性的内容(__u_boot_cmd_start、__u_boot_cmd_end)连续排布在一起。这样可以通过类似数组方便地访问,但又不需要担心会越界。
十三、uboot的环境变量
1、默认环境变量,在uboot/common/env_common.c中default_environment,这东西本质是一个字符数组,大小为CFG_ENV_SIZE(16kb),里面内容就是很多个环境变量连续分布组成的,每个环境变量最末端以’\0’结束,最终整体结束再追加一个’\0’。
2、刚烧录的系统中环境变量分区是空白的,uboot第一次运行时加载的是uboot代码中自带的一份环境变量,叫默认环境变量。我们在saveenv时DDR中的环境变量会被更新到SD卡中的环境变量中,就可以被保存下来,下次开机会在环境变量relocate时会SD卡中的环境变量会被加载到DDR中去。
3、default_environment中的内容虽然被uboot源代码初始化为一定的值(这个值就是默认环境变量),但是在uboot启动的第二阶段,env_relocate时代码会去判断SD卡(指的是内部iNand)中的env分区的crc是否通过。如果crc校验通过,则relocate函数会从SD卡中读取环境变量来覆盖default_environment字符数组,从而每次开机可以保持上一次更改过的环境变量。
4、printenv、setenv、saveenv的实现。uboot中setenv和saveenv分析
十四、uboot的内存分布、flash分布
uboot烧录到设备内部iNand后,推荐的分区(一个扇区512字节)。