17.U-boot的工作流程分析-6410

17.U-boot的工作流程分析-6410

6410开发板:

1.uboot的入口:

要看uboot工程的入口,首先打开顶层目录的Makefile:

Uboot所支持的开发板,在顶层的Makefile中都会有一个配置选项。比如6410,在Makefile中的配置选项是make forlinx_nand_ram256_config:在vim的命令模式按下/,然后输入make forlinx_nand_ram256_config回车会定位到这里:

这是Makefile里的一个目标。这是来配置6410开发板的。看到上图第二行的smdk6410,这个参数决定了开发板的名称。这个名称是有作用的。接下来看看他的作用。

首先是找一下目录:

可以看到这里有很多smdk的子目录,也包括smdk6410,这两个是对应的。该目录存放的就是6410开发板相关的文件。里面有一个叫uboot.lds的文件,前面知道lds文件是连接器脚本。Uboot的整个过程的链接,是通过该脚本来链接控制的。打开该链接器脚本:

OUTPUT_FORMAT("elf32-littlearm", "elf32-littlearm", "elf32-littlearm")

/*OUTPUT_FORMAT("elf32-arm", "elf32-arm", "elf32-arm")*/

OUTPUT_ARCH(arm)

ENTRY(_start)

SECTIONS

{

????. = 0x00000000;

?

????. = ALIGN(4);

????.text :

????{

???? cpu/s3c64xx/start.o????(.text) //1可以看到位于代码段前端的文件是start.o,对应的是一个汇编文件。这个汇编文件会最先被运行。但是这个汇编代码里最先执行的代码是哪些呢?

?

???? cpu/s3c64xx/s3c6410/cpu_init.o????(.text)

???? cpu/s3c64xx/onenand_cp.o????(.text)

???? cpu/s3c64xx/nand_cp.o????(.text)

???? cpu/s3c64xx/movi.o (.text)

???? *(.text)

???? lib_arm/div0.o

????}

?

????. = ALIGN(4);

????.rodata : { *(.rodata) }

?

????. = ALIGN(4);

????.data : { *(.data) }

?

????. = ALIGN(4);

????.got : { *(.got) }

?

????__u_boot_cmd_start = .;

????.u_boot_cmd : { *(.u_boot_cmd) }

????__u_boot_cmd_end = .;

?

????. = ALIGN(4);

????.mmudata : { *(.mmudata) }

?

????. = ALIGN(4);

????__bss_start = .;

????.bss : { *(.bss) }

????_end = .;

}

?

首先是找到该文件:

上面u-boot-lds文件里,在sections的标识之上,有一行:ENTRY(_start)是整个程序的入口。所以就找找start.S文件里有没_start这个标识呢?一搜会马上看到该标号:

到这里,看到这个_start才是整个uboot工程的入口。

?

接下来是第一阶段的代码:

在Linux里,打开上一节创建好的,Source Insight里的uboot工程:

然后找到smdk6410的start.S:

接下来看uboot做了什么事,主要是通过注释来分析:

开发板一上电,它会跳转到start.S的中断向量表的开始处执行:

从它的注释:

所以1,:知道上电后是跳到中断向量表来执行。执行的第一条指令是b reset。

Start_code的实在start.S的下面定义的:

从注释知道,这是actual start code。进入之后,set the cpu to svc32 mode,设置cpu为SVC模式。

接着执行的代码是:

3.刷新I/D caches。

4.然后是关闭MMU和cache:

5.对外围的基地址进行初始化。

6.接着到了bl lowlevel_init

点击:,然后在Symbol里输入:lowlevel_init:

会看到出现很多,然后在下面可以看到它们各自的目录。其实每一个开发板都对应一个lowlevel_init.S:

进入该文件:

7看到系统进入该文件做的第一件事是:led初始化:

上面是点亮led,是用来帮助调试程序。

8.接着是关闭开门狗的操作:

我们想到在2440里没有关闭看门狗,是不是忘记了呢?看看2440代码:

可以看到2440里的lowlevel_init.S的lowlevel_init标识有一个初始化系统时钟的:bl system_clock_init函数。进入该函数:

可以看到2440是在初始化系统时钟里关闭看门狗。

9.接着还有屏蔽中断的操作:

10.到这才初始化系统时钟:

11.接着初始化串口:

12.对nand进行简单初始化:

13.初始化内存:

初始完内存之后就返回start.S里:

返回:

14.跳转回来之后,由于我们选择的是NandFlash启动,所以是跳转到:

在2440里,是复制NandFlash里的内容到内存当中去。6410也是一样的:

Bl copy_from_nand。

15.接着不管MMU的使能操作:

我们看stack栈的初始化:

16.清除bss段:

?

最后同样是跳转到start_armboot:

我们在2440里讲过,start_armboot的代码,两个板子是同一个文件来的。所以6410的第二阶段与2440的一样的。只有board.c里面有。

验证看看是不是一样的:

?

三:

执行完上面,程序跳转到_start_armboot处执行:

上面的代码,通过伪指令ldr把_start_armboot的值装入pc指针,程序就会跳转到_start_armboot处执行。而此处的地址是start_armboot的地址。就是,程序会跳转到start_armboot函数处执行。就是把我们的pc指针跳转到内存去执行了。

下面看看start_armboot的地址是不是在内存中。

配置uboot:make forlinx_nand_ram256_config,然后执行make。

然后看到生成的文件:

?

其中,u-boot是elf文件,u-boot.bin是二进制文件。

接下来对u-boot的elf文件,进行反汇编,看看start_armboot函数的地址:

arm-linux-objdump -D -S u-boot >dump

查看:

看到函数的其实地址cfe02ad0的地址是在内存里的。所以start.S里的:

实现了从垫脚石跳转到内存。但是,此时会发现在这里的起始地址被变为了cfe02ad0:

在第一阶段里,不是说启动地址是在0吗?为什么这里是cfe02ad0呢?还有就是为什么是这个地址。

?

前面的学习知道,当去链接一个程序的时候,程序由多个文件构成,起始地址是由链接器脚本决定的。在/home/samba/uboot/Uboot/6410/uboot/board/samsung/smdk6410里的u-boot.lds:

起始地址是0:

这里是0,为什么那里会是cfe02ad0呢?我们回到uboot的顶层目录,打开config.mk:

搜索text_base:

找到:

在这里-T $(LDSCRIPT)就是定义使用链接器脚本。后面的-Ttext 是制定代码段的基地址的。$(TEXT_BASE)。这里有两个起始地址,然而程序运行的时候以后面的TEXT_BASE的地址为准。它会覆盖掉LDSCRIPT这个地址。

?

TEXT_BASE是在board/Samsung/smdk6410/config.mk里定义的:

?

接下来就是测试验证一下,把他修改为50008000。然后程序编译:

修改之后,执行make。

反汇编:

arm-linux-objdump -D -S u-boot >dump

上面的起始地址变了,刚才制定的。

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

那起始地址为什么不是0呢?下图:

从上图可以看到,ldr PC,=start_armboot的跳转,把地址从垫脚石跳转到内存里。在前面的代码里,有用到b reset等跳转指令,为什么这不会跳转到内存去执行,而是还在垫脚石里呢?

例如:

上面的跳转,bl lowlevel_init的跳转地址:

为什么PC指针还是在垫脚石中呢?

?

这就得讲两个词了。绝对跳转和相对跳转。

B和bl是相对跳转。

Ldr伪指令是绝对跳转:

?

第三阶段:

是从此函数Start_armboot进入的。主要完成的硬件和软件的初始化,只是一些基础的初始化。

该函数里有一个for循环:

在for里首先是让一个指针数组,把里面的函数指针依次调用一次,if里的判断语句就是函数指针。那么指针数组里有哪些函数指针呢。

?

指针数组:

可以看到里面都是函数指针。这里软件的初始化就不看了,我们只看硬件的初始化。在这些函数指针里,硬件初始化的有串口初始化。Serial_init。接着是lcd的初始化:

初始化网卡:

初始化led:

接着进入一个主循环:

执行用户输入的命令。例如tftp命令。这里是一个死循环。老是等待执行用户继续输入命令。在第一个阶段,每个开发板可能有不同的地方,但是在这个地方都是一样的。就是,在第二阶段都是跳到start_armboot处执行代码。2440的第一阶段是在start.S的b reset开始。

时间: 2024-10-25 11:00:34

17.U-boot的工作流程分析-6410的相关文章

[国嵌笔记][030][U-Boot工作流程分析]

uboot工作流程分析 程序入口 1.打开顶层目录的Makefile,找到目标smdk2440_config的命令中的第三项(smdk2440) 2.进入目录board/samsung/smdk2440/,找到u-boot.lds文件.uboot的链接都是由这个链接器脚本来控制的 3.打开u-boot.lds文件,找到.text(代码段)的第一个文件cup/s3c24xx/start.o,该文件就是uboot的入口代码.链接器脚本中的ENTRY用来表明整个程序的入口,那么标号_start就是整个

18.U-boot的工作流程分析-210

18.U-boot的工作流程分析-210 210启动流程: 前面在2440和6410中虽然有BL1和BL2之分,210也是一样的: ? ? ?

第2章 rsync算法原理和工作流程分析

本文通过示例详细分析rsync算法原理和rsync的工作流程,是对rsync官方技术报告和官方推荐文章的解释. 以下是rsync系列篇: 1.rsync(一):基本命令和用法 2.rsync(二):inotify+rsync详细说明和sersync 3.rsync算法原理和工作流程分析 4.rsync技术报告(翻译) 5.rsync工作机制(翻译) 6.man rsync翻译(rsync命令中文手册) 本文目录: 1.1 需要解决的问题 1.2 rsync增量传输算法原理 1.3 通过示例分析r

16.U-boot的工作流程分析-2440

16.U-boot的工作流程分析-2440 分析的流程: 程序入口 第一阶段程序分析 第二阶段程序分析 2440开发板: 1.uboot的入口: 要看uboot工程的入口,首先打开顶层目录的Makefile: Uboot所支持的开发板,在顶层的Makefile中都会有一个配置选项.比如2440,在Makefile中的配置选项是smdk2440_config:在vim的命令模式按下/,然后输入smdk6410_config回车会定位到这里: 这是Makefile里的一个目标.这是来配置2440开发

大数据技术之_10_Kafka学习_Kafka概述+Kafka集群部署+Kafka工作流程分析+Kafka API实战+Kafka Producer拦截器+Kafka Streams

第1章 Kafka概述1.1 消息队列1.2 为什么需要消息队列1.3 什么是Kafka1.4 Kafka架构第2章 Kafka集群部署2.1 环境准备2.1.1 集群规划2.1.2 jar包下载2.2 Kafka集群部署2.3 Kafka命令行操作第3章 Kafka工作流程分析3.1 Kafka 生产过程分析3.1.1 写入方式3.1.2 分区(Partition)3.1.3 副本(Replication)3.1.4 写入流程3.2 Broker 保存消息3.2.1 存储方式3.2.2 存储策

ios NSURLSession使用说明及后台工作流程分析

转自:http://www.maxiaoguo.com/clothes/268.html NSURLSession是iOS7中新的网络接口,它与咱们熟悉的NSURLConnection是并列的.在程序在前台时,NSURLSession与NSURLConnection可以互为替代工作.注意,如果用户强制将程序关闭,NSURLSession会断掉. NSURLSession提供的功能: 1.通过URL将数据下载到内存 2.通过URL将数据下载到文件系统 3.将数据上传到指定URL 4.在后台完成上述

ios NSURLSession(iOS7后,取代NSURLConnection)使用说明及后台工作流程分析

NSURLSession是iOS7中新的网络接口,它与咱们熟悉的NSURLConnection是并列的.在程序在前台时,NSURLSession与NSURLConnection可以互为替代工作.注意,如果用户强制将程序关闭,NSURLSession会断掉. NSURLSession提供的功能: 1.通过URL将数据下载到内存 2.通过URL将数据下载到文件系统 3.将数据上传到指定URL 4.在后台完成上述功能   工作流程 如果我们需要利用NSURLSession进行数据传输我们需要: 1.创

NSURLSession使用说明及后台工作流程分析

原文摘自http://www.cocoachina.com/industry/20131106/7304.html NSURLSession是iOS7中新的网络接口,它与咱们熟悉的NSURLConnection是并列的.在程序在前台时,NSURLSession与NSURLConnection可以互为替代工作.注意,如果用户强制将程序关闭,NSURLSession会断掉. NSURLSession提供的功能: 1.通过URL将数据下载到内存 2.通过URL将数据下载到文件系统 3.将数据上传到指定

apache shiro的工作流程分析

本文基于shiro的web环境,用宏观(也就是不精确)的角度去理解shiro的工作流程,先看shiro官方的一张图. 和应用程序直接交互的对象是Subject,securitymanager为Subject服务.可以把Subject看成一个用户,你的所有的代码都由用户来执行.suject.execute(callable),这个callable里面就是你的代码. 一.shiro如何介入你的webapp 它是如何初始化的?servletContextListener.它是如何在每个http请求中介