uboot的全局变量gd

本文详细解析了U-Boot启动加载过程中对内存的分配方式,包括全局数据结构gd_t的定义及其存储位置,环境变量与板级信息的数据结构设计等。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

1. 环境变量信息:

typedef	struct environment_s {
	unsigned long	crc;		/* CRC32 over data bytes	*/
#ifdef CFG_REDUNDAND_ENVIRONMENT
	unsigned char	flags;		/* active/obsolete flags	*/
#endif
	unsigned char	data[ENV_SIZE]; /* Environment data		*/
} env_t;

2. 板子信息:

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];
#ifdef CONFIG_HAS_ETH1
    /* second onboard ethernet port */
    unsigned char   bi_enet1addr[6];
#endif
} bd_t;
3. 全局变量

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 */
#ifdef CONFIG_VFD
	unsigned char	vfd_type;	/* display type */
#endif
#if 0
	unsigned long	cpu_clk;	/* CPU clock in Hz!		*/
	unsigned long	bus_clk;
	unsigned long	ram_size;	/* RAM size */
	unsigned long	reset_status;	/* reset status register at boot */
#endif
	void		**jt;		/* jump table */
} gd_t;
声明变量:

在u-boot-1.1.6/include/asm-arm/global_data.h中定义了变量声明的宏:

#define DECLARE_GLOBAL_DATA_PTR     register volatile gd_t *gd asm ("r8")

这个声明告诉编译器使用寄存器r8来存储gd_t类型的指针gd,即这个定义声明了一个指针,并且指明了它的存储位置。
register表示变量放在机器的寄存器
volatile用于指定变量的值可以由外部过程异步修改。

必须在使用gd变量的文件前面用此宏声明变量,才可以使用此变量;

变量的定义:

u-boot-1.1.6/lib_arm/board.c的start_armboot函数中

void start_armboot (void)
{
  .................................
       /* Pointer is writable since we allocated a register for it */
	gd = (gd_t*)(_armboot_start - CFG_MALLOC_LEN - sizeof(gd_t));
	/* compiler optimization barrier needed for GCC >= 3.4 */
	__asm__ __volatile__("": : :"memory");

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

关于gd的存储位置,我们需要了解,uboot 的存储区间分布:见start.S代码:

relocate:				/* relocate U-Boot to RAM	    */
	adr	r0, _start		/* r0 <- current position of code   */
	ldr	r1, _TEXT_BASE		/* test if we run from flash or RAM */
	cmp     r0, r1                  /* don't reloc during debug         比较r0和r1的值,判断代码运行在flash还是在SDRAM中*/
	beq     stack_setup             /*如果r0=r1,代码运行在SDRAM中,设置栈,否则代码在FLASH中,然后把代码复制到SDRAM中*/       
        
	ldr	r2, _armboot_start
	ldr	r3, _bss_start
	sub	r2, r3, r2		/* r2 <- size of armboot, , 得到代码指令段的长度            */
	add	r2, r0, r2		/* r2 <- source end address, r2保存FLASH中代码段的结束地址  */
//复制flash中的代码到SDRAM中
copy_loop:
	ldmia	r0!, {r3-r10}		/* copy from source address [r0]   从flash中读取代码段的内容 */
	stmia	r1!, {r3-r10}		/* copy to   target address [r1]   R1保存SDRAM中,代码运行的开始位置, */
	cmp	r0, r2			/* until source end addreee [r2]    */
	ble	copy_loop
#endif	/* CONFIG_SKIP_RELOCATE_UBOOT */

	/* Set up the stack						    */
stack_setup:
	ldr	r0, _TEXT_BASE		/* upper 128 KiB: relocated uboot   */ 
	sub	r0, r0, #CFG_MALLOC_LEN	/* malloc area      代码段的前面为系统分配内存空间的区域                  */
	sub	r0, r0, #CFG_GBL_DATA_SIZE /* bdinfo        分配内存空间的区域的前面,为全局变量中bdinfo的信息存储区*/
#ifdef CONFIG_USE_IRQ
	sub	r0, r0, #(CONFIG_STACKSIZE_IRQ+CONFIG_STACKSIZE_FIQ) /*中断和快速中断的栈区*/
#endif
	sub	sp, r0, #12		/* leave 3 words for abort-stack  异常堆栈  */

clear_bss:
	ldr	r0, _bss_start		/* find start of bss segment        */
	ldr	r1, _bss_end		/* stop here                        */
	mov 	r2, #0x00000000		/* clear                            */

clbss_l:str	r2, [r0]		/* clear loop...                    */
	add	r0, r0, #4
	cmp	r0, r1
	ble	clbss_l
由上面的分析可以画出,uboot对内存空间的分配情况,如下图所示:


从上面的图,可以看出gd全局变量的位置,得到它的地址也就很简单了!从上面的代码可以看出,bd指针变量,应该指向gd的下半部。

<think>好的,我现在需要回答用户关于U-Boot初始化中gd->mon_len参数的作用的问题。首先,我得回忆一下自己对这个参数的理解,确保信息的准确性。 用户提到的gd是全局数据结构,这在U-Boot中确实存在,通常通过global_data结构体来管理各种全局变量。mon_len这个参数,我记得应该和U-Boot的镜像大小有关。但具体细节可能需要进一步确认。 首先,gd->mon_len中的“mon”可能代表monitor,也就是U-Boot本身,因为U-Boot有时被称为引导监视器。所以这个参数可能是指U-Boot镜像的长度或者占用的内存大小。接下来,我需要考虑这个参数在U-Boot启动过程中的应用场景。 在初始化阶段,U-Boot需要设置内存布局,比如保留区域给自身使用,避免被后续的操作系统或应用覆盖。这时候,知道U-Boot自身的大小就非常重要了。例如,在计算可用内存区域时,需要知道从U-Boot结束的位置之后的内存才是可用的。因此,gd->mon_len可能用于记录U-Boot镜像的长度,从而帮助确定内存的保留区域。 另外,可能涉及到重定位的情况。U-Boot在启动时可能会将自己从加载位置(如Flash)复制到RAM中的运行地址,这时候需要知道镜像的大小才能正确复制。gd->mon_len可能在重定位过程中被设置,确保复制的数据量正确。 还需要考虑这个参数的初始化时机。可能是在板级初始化代码中,通过计算U-Boot的代码段、数据段等的长度总和来赋值给gd->mon_len。例如,使用链接器脚本中的变量来确定镜像的大小。 另外,是否有其他相关的全局变量gd->mon_len配合使用?比如gd->mon_addr,可能记录U-Boot在内存中的起始地址,结合mon_len可以确定整个U-Boot占用的内存范围。 不过,我需要确认这些信息是否正确。可能需要查阅U-Boot的源代码或者相关文档来验证。例如,在U-Boot的启动流程中,board_init_f阶段会初始化全局数据,包括mon_len。在代码中,可能会看到类似gd->mon_len = (ulong)&__bss_end - (ulong)_start; 这样的语句,其中_start和__bss_end是链接器脚本中定义的符号,分别表示U-Boot的起始地址和BSS段的结束地址,这样计算出来的就是整个U-Boot镜像的大小。 总结一下,gd->mon_len的作用是记录U-Boot镜像在内存中的长度,用于内存管理和重定位,确保系统正确保留U-Boot所需的内存空间,避免被其他程序覆盖。同时,在重定位过程中,这个参数帮助确定需要复制的数据量,确保U-Boot正确迁移到新的内存位置。 但需要确认是否有其他用途,比如在内存分配或日志输出中是否用到这个参数。或者在某些架构中是否有特殊处理。可能需要进一步查阅代码或资料,但根据现有知识,这个理解应该是正确的。</think>在U-Boot初始化过程中,`gd->mon_len`参数的作用如下: --- ### **核心作用** `gd->mon_len`(Monitor Length)用于记录**U-Boot自身镜像在内存中的长度**,是内存管理和重定位的关键参数。 --- ### **具体应用场景** 1. **内存布局规划** - U-Boot需要为自身保留内存区域,防止被内核或应用覆盖。 - 通过`gd->mon_len`和`gd->mon_addr`(U-Boot镜像起始地址)可确定保留的内存范围: $$ \text{保留区域} = [\text{mon\_addr}, \text{mon\_addr} + \text{mon\_len}) $$ 2. **重定位(Relocation)** - U-Boot启动时可能从Flash复制自身到RAM运行。 - `gd->mon_len`确保复制完整的镜像: ```c memcpy(new_addr, old_addr, gd->mon_len); // 伪代码示例 ``` 3. **可用内存计算** - 系统可用内存起始地址 = `gd->mon_addr + gd->mon_len`,避免内存冲突。 --- ### **技术实现** - **初始化时机**:在`board_init_f`阶段(早期初始化)通过链接器脚本计算得出。 - **计算公式**: $$ \text{mon\_len} = \text{\_\_bss\_end} - \text{\_start} $$ 其中: - `_start`:U-Boot代码段起始地址(链接器脚本定义)。 - `__bss_end`:BSS段结束地址,表示U-Boot镜像的末尾。 --- ### **与其他参数的关系** - `gd->mon_addr`:U-Boot镜像的加载地址。 - `gd->ram_top`:系统可用内存顶端,依赖`mon_len`计算。 --- ### **典型代码逻辑** ```c // 伪代码:初始化gd->mon_len gd->mon_len = (unsigned long)&__bss_end - (unsigned long)_start; ``` --- ### **总结** `gd->mon_len`是U-Boot内存管理的基石,确保: 1. 自身镜像完整性 2. 正确划分保留内存与可用内存 3. 支持安全的重定位操作 此参数由链接阶段动态生成,直接反映U-Boot镜像的实际大小。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值