技术心得:基于AR9331(MIPS架构)分析系统启动过程(uboot)

简介: 技术心得:基于AR9331(MIPS架构)分析系统启动过程(uboot)

前提:


1.AR9331是基于MIPS 24K CPU的一款WIFI1X1芯片,其SDK采用uboot作为引导。AR9331中定义的基地址是:0x9f00,0000


2.MIPS24K芯片,将固定的起始地址,规定为0xBF00,0000(见 和有提到)


此地址属于MIPS的KSEG1的地址范围内(见其实际的物理地址是:0x1F00,0000(=0xBF00,0000 & 0x1FFF,FFFF)


A.


uboot在编译时,会经历如下动作:


bootstrap: depend version $(SUBDIRS) $(OBJS_BOOTSTRAP) $(LIBS_BOOTSTRAP) $(LDSCRIPT_BOOTSTRAP)


UNDEF_SYM=$(OBJDUMP) -x $(LIBS_BOOTSTRAP) |sed -n -e 's/.*\(__u_boot_cmd_.*\)/-u\1/p'|sort|uniq;\


$(LD) $(LDFLAGS_BOOTSTRAP【xxx1】 ) $$UNDEF_SYM $(OBJS_BOOTSTRAP) \

--start-group $(LIBS_BOOTSTRAP) --end-group $(PLATFORM_LIBS) \

-Map bootstrap.map -o bootstrap

u-boot: depend version $(SUBDIRS) $(OBJS) $(LIBS) $(LDSCRIPT)

UNDEF_SYM=`$(OBJDUMP) -x $(LIBS) |sed -n -e 's/.*\(__u_boot_cmd_.*\)/-u\1/p'|sort|uniq`;\

$(LD) $(LDFLAGS)【xxx2】 $$UNDEF_SYM $(OBJS) $(BOARD_EXTRA_OBJS) \


--start-group $(LIBS) --end-group $(PLATFORM_LIBS) \


-Map u-boot.map -o u-boot


以及


u-boot.lzimg: $(obj)u-boot.bin System.map


@$(LZMA) e $(obj)u-boot.bin u-boot.bin.lzma


@./tools/mkimage -A mips -T firmware -C lzma \


-a 0x$(shell grep "T _start" $(TOPDIR)/System.map | awk '{ printf "%s", $$1 }') \

-e 0x$(shell grep "T _start" $(TOPDIR)/System.map | awk '{ printf "%s", $$1 }') \


【xxx3】 -n 'u-boot image' -d $(obj)u-boot.bin.lzma $@


也就是说,在编译的时候,就决定了tuboot需要在0x9f000000处被引导启动,也就是说,烧写tuboot时,需要烧到0x9f000000【xxx4】 处。


而0x9F00,0000属于KSEG0范围,其实际对应的物理地址也是0x1F00,0000【xxx5】 (=0x9F00,0000&0x7FFF,FFFF)


B. Uboot编译连接脚本文件,在ap121上,就是/boot/u-boot/board/ar7240/ap121/u-boot.lds


此文件的作用:


2 连接脚本是用来描述输出文件的内存布局;源代码经过编译器编译后包含如下段:


n 正文段text:包含程序的指令代码;


n 数据段data:包含固定的数据,如常量和字符串;


n 未初始化数据段:包含未初始化的变量、数组等。


连接器的任务是将多个编译后的文件的text、data和bass等段连接在一起;而连接脚本文件就是告诉连接器从什么地址(运行时地址)开始放置这些段


2 此文件中,最要关注的是.text字段。一切从这里开始


C. 先运行bootstrap,然后再运行uboot


在\boot\u-boot\board\ar7240\ap121\u-boot-bootstrap.lds,有定义:ENTRY(_start_bootstrap)


在\boot\u-boot\board\ar7240\ap121\u-boot.lds,有定义:ENTRY(_start)


而在boot\u-boot\board\ar7240\ap121\config.mk,有定义:


# ROM version


ifeq ($(COMPRESSED_UBOOT),1)


TEXT_BASE = 0x80010000 #对应uboot的TEXT正文地址,见u-boot.map的_start


BOOTSTRAP_TEXT_BASE = 0x9f000000 #对应bootstrap的TEXT正文地址,见bootstrap.map的_start_bootstrap


【xxx6】 else


TEXT_BASE = 0x9f000000


Endif


所以,先执行_start_bootstrap,再执行_start。那么,这两个在哪儿?


D. 在bootstrap.map中,可以看到:


.text 0x000000009f000000 0x3aa0


(.text)


.text 0x000000009f000000 0x8b0 cpu/mips/start_bootstrap.o


0x000000009f000000 _start_bootstrap


Address of section .text set to 0x9f000000


在u-boot.map中,可以看到:


.text 0x0000000080010000 0x17da0


(.text)


.text 0x0000000080010000 0x3350 cpu/mips/start.o


0x0000000080010030 relocate_code


0x0000000080010000 _start


Address of section .text set to 0x80010000


然后,在boot/u-boot/cpu/mips中,可以找到:start_bootstrap.S和start.S


这两个,就是真正执行_start_boostrap和_start的地方


start_bootstrap中,可以看到:bootstrap_board_init_f和bootstrap_board_init_r。最后,在bootstrap_board_init_r中,有:


addr = (char )(BOOTSTRAP_CFG_MONITOR_BASE + ((ulong)&uboot_end_data_bootstrap - dest_addr));


memmove (&header, (char )addr, sizeof(image_header_t));


以及:


data = addr + sizeof(image_header_t);/越过uboot的头,定位到uboot的净荷开始/


fn = ntohl(hdr->ih_load);/*定位位于hdr->ih_load位置的起止程序,并执行之。这个程序就是start/


(fn)(gd->ram_size);


可见,bootstrap中会定位并剥掉uboot的image_header_t的头,这样就会调位到start。


下面,分析_start


E. 在start.S中,可以看到:board_init_f和board_init_r(boot/u-boot/lib_mips/board.c)。这就是从汇编进入C的两个入口。先board_init_f,再board_init_r;


最终,在board_init_r中,调用无限循环:


for (;;) {


main_loop ();


}


F. main_loop(boot/u-boot/common/main.c)中,最终会调用:run_command (lastcommand, flag);


G. 在run_command(boot/u-boot/common/main.c)中,利用find_cmd找到合适的cmd_tbl_t *cmdtp对象,最后执行((cmdtp->cmd) (cmdtp, flag, argc, argv)


并且,在cmd_bootm.c中,有定义:


U_BOOT_CMD(


bootm, CFG_MAXARGS, 1, do_bootm,


"bootm - boot application image from memory\n",


"【addr 【arg ...】】\n - boot application image stored in memory\n"


"\tpassing arguments 'arg ...'; when booting a Linux kernel,\n"


"\t'arg' can be the address of an initrd image\n"


);


在boot/u-boot/include/command.h中,有定义:


#define U_BOOT_CMD(name,maxargs,rep,cmd,usage,help) \


cmd_tbl_t u_bootcmd##name Struct_Section = {#name, maxargs, rep, cmd, usage}


那么,最初的((cmdtp->cmd) (cmdtp, flag, argc, argv),就会执行到do_bootm


H. 在boot模式下,敲入printenv,可以看到uboot所用到的环境变量的值:


ar7240> printenv


bootargs=console=ttyS0,115200 root=31:02 rootfstype=squashfs init=/sbin/init mtdparts=ar7240-nor0:256k(u-boot),64k(u-boot-env),2752k(rootfs),896k(uImage),64k(NVRAM),64k(ART)【xxx7】


bootcmd=bootm 0x9f300000【xxx8】


bootdelay=4【xxx9】


baudrate=115200


ethaddr=0x00:0xaa:0xbb:0xcc:0xdd:0xee


ipaddr=192.168.1.2【xxx10】


serverip=192.168.1.10【xxx11】


stdin=serial


stdout=serial


stderr=serial


ethact=eth0


这些环境变量的定义,是在boot/u-boot/common/environment.c中赋值的;而具体的来源,则大部分在文件boot/u-boot/include/configs/ap121.h中定义;并且这些宏定义,是通过boot/u-boot/common/env_nowhere.c中的env_init引导的。


I. 在编译内核镜像时,有如下命令:


/home/xxx/140703_AR9331_Dev/u11_OnlyBasicAndWLAN_AP121-4MB/build/../boot/u-boot/tools/mkimage -A mips -O linux -T kernel -C gzip -a 0x80002000 -e 0x8019bd60 -n Linux Kernel Image -d /home/xxx/140703_AR9331_Dev/u11_OnlyBasicAndWLAN_AP121-4MB/build/../linux/kernels/mips-linux-2.6.31/arch/mips/boot/vmlinux.bin.gz /home/xxx/140703_AR9331_Dev/u11_OnlyBasicAndWLAN_AP121-4MB/build/../images/ap121-2.6.31/vmlinux.gz.uImage【xxx12】


J. Uboot启动内核,是调用cmd_bootm.c中的do_bootm函数,其传入的命令参数就是:


bootm 0x9f300000【xxx13】


然后,可以看到如下的启动信息:


## Booting image at 9f300000 ... 【xxx14】


Image Name: Linux Kernel Image


Created: 2013-02-06 22:27:48 UTC


Image Type: MIPS Linux Kernel Image (lzma compressed)


Data Size: 771996 Bytes = 753.9 kB


Load Address: 80002000 【xxx15】


Entry Point: 8019bd60【xxx16】


Verifying Checksum at 0x9f300040 ...OK


Uncompressing Kernel Image ... OK


上述这些信息,都是do_bootm函数中,读取镜像文件头image_header_t信息后得出的


然后,利用gunzip ((void )ntohl(hdr->ih_load), unc_len, (uchar )data, &len) != 0),将压缩的镜像文件解压缩到hdr->ih_load【xxx17】 指向的地址。


最后,调用do_bootm_linux (cmdtp, flag, argc, argv,addr, len_ptr, verify); 开始内核启动过程


K. do_bootm_linux(boot/u-boot/lib_mips/mips_linux.c) :


2 获得内核镜像的启动地址:


theKernel =


(void ()(int, char , char , int)) ntohl (hdr->ih_ep);


2 【xxx18】 解析boot_args字段,得到:


linux_params_init (UNCACHED_SDRAM (gd->bd->bi_boot_params), commandline);


2 最后,直接运行内核镜像的启动地址:


flash_size_mbytes = gd->bd->bi_flashsize/(1024 1024);


theKernel (linux_argc, linux_argv, linux_env, flash_size_mbytes);【xxx19】


L. entry: 0x8019bf90地址上的程序,是什么呢?


看一下:linux/kernels/mips-linux-2.6.31/System.map,搜索8019bf9,会发现:


ffffffff8019bf90 T kernel_entry


哈哈,原来该地址上的程序是:kernel_entry


M. kernel_entry在arch/mips/kernel/head.S中定义;并且最终会跳转到start_kernel函数,从而进入C代码


N. 这里就调用了start_kernel(linux/kernels/mips-linux-2.6.31/init/main.c)


//代码参考:https://weibo.com/u/7930570539

O. Start_kernel->rest_init->kernel_thread(【xxx20】kernel_init, NULL, CLONE_FS | CLONE_SIGHAND);->kernel_init->init_post->run_init_process("/sbin/init"); --> 进入busybox的init流程


【xxx1】## LDFLAGS_BOOTSTRAP 中,含有-Bstatic -T $(LDSCRIPT_BOOTSTRAP) -Ttext $(BOOTSTRAP_TEXT_BASE) $(PLATFORM_LDFLAGS)


## BOOTSTRAP_TEXT_BASE,在boot\u-boot\board\ar7240\ap121\config.mk中有定义,指明了BOOTSTRAP_TEXT_BASE = 0x9f000000,即bootstrap的报文段会从此地址开始。


## 那么,也就是要求:需要将tuboot放到0x9f000000处。这样tuboot启动时,才能找到这里的正确位置


【xxx2】## LDFLAGS += -Bstatic -T $(LDSCRIPT) -Ttext $(TEXT_BASE) $(PLATFORM_LDFLAGS)


## 其中的$(TEXT_BASE)在boot\u-boot\board\ar7240\ap121\config.mk中有定义,指明了TEXT_BASE = 0x80010000,即uboot的报文段会从此地址开始


【xxx3】


-a 0xffffffff80010000 \


-e 0xffffffff80010000 \


【xxx4】0x9f000000位于KSEG0地址段,其距离KSEG0地址段上限(0x9fffffff)还有0x1000000,即16M的空间。也就是说,设置0x9f000000作为基地址,也就意味着AR9331可以支持最多16MB Flash ---我的猜测,不知道是否正确


【xxx5】和MIPS24K的固定起始地址是一样的。这就是为何要规定基地址是0x9F00,0000的缘故


【xxx6】这是u-boot和bootstrap在内存中的运行域


【xxx7】由ap121.h中的CONFIG_BOOTARGS定义


表示传递给内核的启动参数


【xxx8】由ap121.h中的CONFIG_BOOTCOMMAND定义


表示自动启动时执行的命令


这里的0x9f300000就是linux内核的TEXT_BASE地址;这也正是uboot下的cp.b命令烧写Linux

相关文章
|
15天前
|
存储 分布式计算 关系型数据库
架构/技术框架调研
本文介绍了微服务间事务处理、调用、大数据处理、分库分表、大文本存储及数据缓存的最优解决方案。重点讨论了Seata、Dubbo、Hadoop生态系统、MyCat、ShardingSphere、对象存储服务和Redis等技术,提供了详细的原理、应用场景和优缺点分析。
|
1天前
|
人工智能 前端开发 编译器
【AI系统】LLVM 架构设计和原理
本文介绍了LLVM的诞生背景及其与GCC的区别,重点阐述了LLVM的架构特点,包括其组件独立性、中间表示(IR)的优势及整体架构。通过Clang+LLVM的实际编译案例,展示了从C代码到可执行文件的全过程,突显了LLVM在编译器领域的创新与优势。
17 3
|
6天前
|
机器学习/深度学习 存储 人工智能
【AI系统】模型演进与经典架构
本文探讨了AI计算模式对AI芯片设计的重要性,通过分析经典模型结构设计与演进、模型量化与压缩等核心内容,揭示了神经网络模型的发展现状及优化方向。文章详细介绍了神经网络的基本组件、主流模型结构、以及模型量化和剪枝技术,强调了这些技术在提高模型效率、降低计算和存储需求方面的关键作用。基于此,提出了AI芯片设计应考虑支持神经网络计算逻辑、高维张量存储与计算、灵活的软件配置接口、不同bit位数的计算单元和存储格式等建议,以适应不断发展的AI技术需求。
21 5
|
15天前
|
传感器 算法 物联网
智能停车解决方案之停车场室内导航系统(二):核心技术与系统架构构建
随着城市化进程的加速,停车难问题日益凸显。本文深入剖析智能停车系统的关键技术,包括停车场电子地图编辑绘制、物联网与传感器技术、大数据与云计算的应用、定位技术及车辆导航路径规划,为读者提供全面的技术解决方案。系统架构分为应用层、业务层、数据层和运行环境,涵盖停车场室内导航、车位占用检测、动态更新、精准导航和路径规划等方面。
66 4
|
16天前
|
Kubernetes Cloud Native 持续交付
云原生技术在现代应用架构中的实践与思考
【10月更文挑战第38天】随着云计算的不断成熟和演进,云原生(Cloud-Native)已成为推动企业数字化转型的重要力量。本文从云原生的基本概念出发,深入探讨了其在现代应用架构中的实际应用,并结合代码示例,展示了云原生技术如何优化资源管理、提升系统弹性和加速开发流程。通过分析云原生的优势与面临的挑战,本文旨在为读者提供一份云原生转型的指南和启示。
31 3
|
16天前
|
运维 Kubernetes Cloud Native
云原生技术在现代应用架构中的实践与挑战####
本文深入探讨了云原生技术的核心概念、关键技术组件及其在实际项目中的应用案例,分析了企业在向云原生转型过程中面临的主要挑战及应对策略。不同于传统摘要的概述性质,本摘要强调通过具体实例揭示云原生技术如何促进应用的灵活性、可扩展性和高效运维,同时指出实践中需注意的技术债务、安全合规等问题,为读者提供一幅云原生技术实践的全景视图。 ####
|
17天前
|
缓存 负载均衡 JavaScript
探索微服务架构下的API网关模式
【10月更文挑战第37天】在微服务架构的海洋中,API网关犹如一座灯塔,指引着服务的航向。它不仅是客户端请求的集散地,更是后端微服务的守门人。本文将深入探讨API网关的设计哲学、核心功能以及它在微服务生态中扮演的角色,同时通过实际代码示例,揭示如何实现一个高效、可靠的API网关。
|
15天前
|
Cloud Native 安全 数据安全/隐私保护
云原生架构下的微服务治理与挑战####
随着云计算技术的飞速发展,云原生架构以其高效、灵活、可扩展的特性成为现代企业IT架构的首选。本文聚焦于云原生环境下的微服务治理问题,探讨其在促进业务敏捷性的同时所面临的挑战及应对策略。通过分析微服务拆分、服务间通信、故障隔离与恢复等关键环节,本文旨在为读者提供一个关于如何在云原生环境中有效实施微服务治理的全面视角,助力企业在数字化转型的道路上稳健前行。 ####
|
16天前
|
Dubbo Java 应用服务中间件
服务架构的演进:从单体到微服务的探索之旅
随着企业业务的不断拓展和复杂度的提升,对软件系统架构的要求也日益严苛。传统的架构模式在应对现代业务场景时逐渐暴露出诸多局限性,于是服务架构开启了持续演变之路。从单体架构的简易便捷,到分布式架构的模块化解耦,再到微服务架构的精细化管理,企业对技术的选择变得至关重要,尤其是 Spring Cloud 和 Dubbo 等微服务技术的对比和应用,直接影响着项目的成败。 本篇文章会从服务架构的演进开始分析,探索从单体项目到微服务项目的演变过程。然后也会对目前常见的微服务技术进行对比,找到目前市面上所常用的技术给大家进行讲解。
35 1
服务架构的演进:从单体到微服务的探索之旅
|
14天前
|
消息中间件 监控 安全
后端架构演进:从单体到微服务####
在数字化转型的浪潮中,企业应用的后端架构经历了从传统单体架构到现代微服务架构的深刻变革。本文探讨了这一演进过程的背景、驱动力、关键技术及面临的挑战,揭示了如何通过微服务化实现系统的高可用性、扩展性和敏捷开发,同时指出了转型过程中需克服的服务拆分、数据管理、通信机制等难题,为读者提供了一个全面理解后端架构演变路径的视角。 ####
37 8