uboot移植(五)——uboot启动的第二阶段(gd和bd)

之前uboot启动第一阶段的最后将指针指向了start_armboot这个函数,这里也

是uboot启动的第二阶段的开始并且uboot启动第二阶段大部分是在这个函数中完成

的。

DECLARE_GLOBAL_DATA_PTR;这个宏在大部分中的文件中都有这个宏,这个宏的

实际定义是在include/asm-arm/Global_data.h

#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类型变量的指针。gd_t中定义了很多全局变量,都是整个uboot使用的,其中有一个bd_t类型的指针bd,指向结构体bd_info,这个结构体里面定义的是和开发板硬件先关的全局变量(譬如 ip地址  串口波特率 等)

全局变量gd是uboot中很重要的一个全局变量(准确的说这个全局变量是一个结构体,里面有很多内容,这些内容加起来构成的结构体就是uboot中常用的所有全局变量),由于gd经常被访问,因此放在寄存器中提升访问效率。

gd_base = CFG_UBOOT_BASE + CFG_UBOOT_SIZE - CFG_MALLOC_LEN -  CFG_STACK_SIZE - 
            sizeof(gd_t);

//uboot区:CFG_UBOOT_BASE (33e00000)+CFG_UBOOT_SIZE(uboot的实际大小,我们这里给了2M)

//堆区:长度为CFG_MALLOC_LEN ,实际长度为912KB

//栈区:长度为CFG_STACK_SIZE,实际长度为512KB

//gd:长度为sizeof(gd_t),实际为36字节

//bd:长度为sizeof(bd_t),实际长度为44字节左右

//所以gd_base的大概位置是离uboot起始地址(33e00000)往上走624KB的位置处

gd = (gd_t*)gd_base;

//上面已经得到gd_base是一个内存地址,然后通过强制类型转换使其变为一个指针,并赋给gd,使得gd指向这段内存空间

memset ((void*)gd, 0, sizeof (gd_t)); 
gd->bd = (bd_t*)((char*)gd - sizeof(bd_t));
 memset (gd->bd, 0, sizeof (bd_t));

上面提到的gd只是一个指针,而并没有给它分配内存空间,并在使用之前对这片内存清零。后面使用了类似的方法给bd分配内存空间,并在使用前进行对这片内存空间进行清零。通过分析可知,gd就在bd的上面,两片内存空间紧挨着(中间隔了bd的大小)

typedef struct bd_info {
    int            bi_baudrate;    /* serial console baudrate */
    unsigned long    bi_ip_addr;    /* IP Address */
    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 */
    struct                /* RAM configuration */
    {
    ulong start;
    ulong size;
    }            bi_dram[CONFIG_NR_DRAM_BANKS];
    
 typedef    struct    global_data {
    bd_t        *bd;
    unsigned long    flags;
    unsigned long    baudrate;
    unsigned long    have_console;    /* serial_init() was called */
    unsigned long    reloc_off;    /* Relocation Offset */
    unsigned long    env_addr;    /* Address  of Environment struct */
    unsigned long    env_valid;    /* Checksum of Environment valid? */
    unsigned long    fb_base;    /* base address of frame buffer */

以上便是gd和bd这个两个全局变量指向的结构体的内容

时间: 2024-10-20 13:09:15

uboot移植(五)——uboot启动的第二阶段(gd和bd)的相关文章

OK6410 uboot移植之sd启动

1  uboot移植 1.1移植准备工作 1.1.1安装交叉编译工具链 版本:arm-linux-gcc 4.4.1 环境:ubuntu14.04.01LTS 1.1.2建立OK6410配置项 从官网下载u-boot-2012.10.tar.bz2,由于uboot支持的smdk6400单板与我们的板子OK6410最相似,所以修改是基于smdk6400进行的,初步修改uboot建立OK6410配置项. 详细修改过程如下: 进入u-boot-2012.10顶层目录,在board/Samsung目录下

uboot移植之uboot命令体系解析

1:回归到main_loop uboot启动第二阶段的最后,进入死循环main_loop()函数,命令行中没输出一次命令,就会执行一次main_loop函数,完成一次命令的获取.解析和执行. 2:uboot命令体系的实现原理 uboot中里面维护了很多命令,每个命令对应一个结构体变量,当我们在命令行输入一个命令时.这时就涉及如何去维护这些命令的问题,一般的方法有两种,数组或者链表,但是数组的缺陷在开始的时候需要确定数组的大小,链表的话效率比较低,所以uboot使用了另一种方式.uboot中一个命

uboot移植一uboot架构分析

开发环境: 1 .开发板mini2440 2. u-boot-2010.12 参考i资料:https://blog.csdn.net/androidbbc/article/details/50961163 http://www.cnblogs.com/kele-dad/p/8969174.html 一.下载u-boot- 2010.12,并且解压 二.分析u-boor-2010.12 api: 存放uboot提供的接口函数 config.mk: 根据不同开发板定制的代码,代码也不少 driver

uboot移植之uboot中的SD卡驱动解析

1:地址对硬件操作的影响 (1)操作系统(指的是linux)下MMU肯定是开启的,也就是说linux驱动中肯定都使用的是虚拟地址.而纯裸机程序中根本不会开MMU,全部使用的是物理地址.这是裸机下和驱动中操控硬件的一个重要区别. (2)uboot早期也是纯物理地址工作的,但是现在的uboot开启了MMU做了虚拟地址映射,这个东西驱动也必须考虑.查uboot中的虚拟地址映射表,发现210开发板里面,除了0x30000000-0x3FFFFFFF映射到了0xC0000000-0xCFFFFFFF之外,

uboot移植之前的工作

1.1计算机系统的主要部件:计算机系统是有cpu来做核心进行运行的系统.典型的计算机系统有:pc机,嵌入式设备(手机.平板电脑.游戏机),单片机(家用电器). 1.2计算机系统组件部件非常多,不同的计算机系统组成部件也不同.但是所有的计算机系统运行时需要的主要核心部件都是3个东西:cpu+外部存储器(Flash/硬盘) + 内部存储器(DDR SDRAM/SDRAM/SRAM). 1.3pc机的启动过程:(1)典型的pc部署:BIOS程序部署在pc机主板上(随主板出厂时已经预制了),操作系统部署

I.MX6Q(TQIMX6Q/TQE9)学习笔记——新版BSP之u-boot移植

前段时间就开始学习I.MX6Q了,但是最近工作实在是忙,间断了一些时间了.为了提高移植效率,还是考虑移植Freescale维护的3.10版本的内核. 源码获取 Freescale维护的3.10的内核是使用git管理的,但是直接使用git下载代码会比较慢,下面是我下载好的uboot和kernel: I.MX6Q BSP源码(Freescale官方维护) 代码下载好后,先将u-boot解压到工作目录,然后在终端下切换到uboot根目录.由于这个版本的bsp是使用git管理的,因此,需要切换到指定分支

u-boot移植启动流程详细分析(2)

学习底层的东西,首要的就是去了解他的架构,整体的思路知道了,就会在出现问题的时候有很清晰的思路,知道哪里出的问题,以及程序是如何执行的,相信做到上面的,所遇到的问题,大都会迎刃而解了吧,高手是有很多的,所谓的高手,不过也就那样吧,努力努力也是可以赶超的. 之前,介绍了u-boot的第一阶段的启动流程,那么接下来就来说说第二阶段的具体执行流程: (1)初始化gloabl data和board data,这里所谓的初始化就是给他们分配一块内存空间. (2)初始化序列(init_sequence) 在

uboot移植(四)——uboot启动第一阶段

1:BL0 BL1 BL2分别是什么 (1)BL0:s5pv210的iROM中固化的代码 作用:初始化系统时钟,设置看门狗,初始化栈,加载BL1 (2)BL1:从外部启动介质(nand/SD卡)中加载的uboot.bin的前16K代码 作用:初始化RAM,关闭Cache,初始化DDR,设置栈,加载BL2 (3)BL2:是指在代码完成重定位后在DDR中运行的完整的uboot代码 作用:初始化其他外设,加载OS内核 三者的关系:开机上电自动运行BL0的代码,然后加载BL1到SDRAM中,接着通过重定

嵌入式linux开发uboot移植(三)——uboot启动过程源码分析

嵌入式linux开发uboot移植(三)--uboot启动过程源码分析 一.uboot启动流程简介 与大多数BootLoader一样,uboot的启动过程分为BL1和BL2两个阶段.BL1阶段通常是开发板的配置等设备初始化代码,需要依赖依赖于SoC体系结构,通常用汇编语言来实现:BL2阶段主要是对外部设备如网卡.Flash等的初始化以及uboot命令集等的自身实现,通常用C语言来实现. 1.BL1阶段 uboot的BL1阶段代码通常放在start.s文件中,用汇编语言实现,其主要代码功能如下: