uboot中setenv和saveenv分析

转:https://blog.csdn.net/weixin_34355715/article/details/85751477

Env在u-boot中通常有两种存在方式,在永久性存储介质中(flash、NVRAM等),在SDRAM中。可配置不适用env的永久存储方式,但不常用。U-boot在启动时会将存储在永久性存储介质中的env重新定位到RAM中,这样可以快速访问,同时可以通过saveenv将RAM保存到永久性存储介质中。

  1. 相关结构体

env_t定义于include/environment.h中

typedef struct environment_s {

uint32_t crc; /* CRC32 over data bytes */

#ifdef CFG_REDUNDAND_ENVIRONMENT

unsigned char flags; /* active/obsolete flags */

#endif

unsigned char data[ENV_SIZE];

} env_t;

结构说明:

crc是u-boot在保存env的时候加上去的校验头,在第一次启动时一般crc校验会出错,这很正常,因为此时Flash中的数据无效。

data字段保存实际的环境变量。U-boot的env采用name=value”\0”的方式存储,在所有env的最后以“\0\0”表示整个env的结束。新的name=value对总是被添加到env数据块的末尾,当删除一个name=value对时,后面的环境变量将前移,对一个已经存在的环境变量的修改实际上先删除再插入。

env会从flash等存储设备重定位到RAM中,在env的不同实现版本(env_xxx.c)中定义了env_ptr,它指向env在RAM中的位置。u-boot在重定位env后对环境变量的操作都是针对env_ptr。

env_embedded.c-----env和uboot存储于同一块区。

env_nand.c------------env存储在nandflash中。

env_dataflash.c --env存储在dataflash中。

env_eeprom.c --env存储在eeprom中。

env_flash.c --env存储在norflash中。

env_ptr指向环境参数区,系统启动时默认的环境参数default_environment[],定义于common/env_common.c中

uchar default_environment[] = {

61 #ifdef CONFIG_BOOTARGS

62 "bootargs=" CONFIG_BOOTARGS "\0"

63 #endif

64 #ifdef CONFIG_BOOTCOMMAND

65 "bootcmd=" CONFIG_BOOTCOMMAND "\0"

66 #endif

......

127 #if defined(CONFIG_PCI_BOOTDELAY) && (CONFIG_PCI_BOOTDELAY > 0)

128 "pcidelay=" MK_STR(CONFIG_PCI_BOOTDELAY) "\0"

129 #endif

130 #ifdef CONFIG_EXTRA_ENV_SETTINGS

131 CONFIG_EXTRA_ENV_SETTINGS

132 #endif

133 "\0"

134 };

参数解释如下:

bootfile 定义缺省的下载文件

bootargs 定义传递给Linux内核的命令行参数

bootcmd 定义自动启动时执行的几条命令

serverip 定义tftp服务器端的IP地址

env_t中除了数据之外还包含校验头,u-boot把env_t的数据指针又保存在另外一个地方,这就是gd_t数据结构(不同平台有不同的gd_t),这里以ARM为例仅列出env相关的部分。

typedef struct global_data

{

……

unsigned long env_off;

unsigned long env_addr;

unsigned long env_valid; /* checksum of environment valid */

……

} gd_t;

<include/asm-arm/global_data.h>

gd_t.env_addr即指向env_ptr->data。

  1. 相关文件

common/env_common.c

供u-boot调用的通用函数接口,它们隐藏了env的不同实现方式,比如dataflash、eeprom、flash等。

common/env_dataflash.c

env存储在dataflash中的实现

common/cmd_nvedit.c

实现u-boot对环境变量的操作命令

environment.c

环境变量以及一些宏定义

env如果存储在flash中还需要flash的支持。

  1. 环境变量操作流程

Env初始化

Start_armboot:lib_arm/board.c

*env_init:env_xxx.c(xxx = nand|flash|eeprom……)

env_relocate:env_common.c

*env_relocate_spec:env_xxx.c

ENV_IS_EMBEDDED:env是否存在于u-boot TEXT段中。

CFG_ENV_SIZE:env块的大小。

CFG_ENV_IS_IN_NAND:env块是否存在Nand Flash中。

CFG_ENV_OFFSET:env块在Flash中偏移地址。

  1. env_init

实现env的第一次初始化,对于nand env(非embedded方式):

env_nand.c:env_int

gd->env_addr = (ulong)&default_environment[0];

gd-env_valid = 1;

  1. env_relocate

env_common.c:env_relocate

DEBUGE(“%s[%d] offset = 0x%lx\n”, __FUNCTION__, __LINE__, gd->reloc_off);

env_ptr = (env_t *)malloc(CFG_ENV_SIZE);

DEBUGE(“%s[%d] malloced ENV at %p\n”, __FUNCTION__, __LINE__, env_ptr);

env_relocate_spec();

gd->env_addr = (ulong)&(env_ptr->data);

  1. env_relocate_spec

size_t total;

ret = readenv(CFG_ENV_OFFSET, (u_char *) env_ptr);

// nand_read(&nand_info[0], CFG_ENV_OFFSET, &total, (u_char *)env_ptr);

if(ret || total!= CFG_ENV_SIZE)

return use_default();

if(crc32(0, env_ptr->data, ENV_SIZE) != env_ptr->crc)

return use_default();

env_relocate_spec的意图就是调用nand_read将环境变量从CFG_ENV_OFFSET处读出,环境变量的大小为CFG_ENV_SIZE(注意CFG_ENV_OFFSET和CFG_ENV_SIZE要和nandflash的块/页边界对齐。读出数据后再调用crc32对env_ptr->data进行校验并与保存在env_ptr->crc的校验码对比,确认数据是否出错。从这里可以看出在系统第一次启动时,Nand Flash里面没有存储任何环境变量,crc校验肯定出错,当我们保存环境变量后,接下来在启动板子u-boot就不会再报crc32出错了。

  1. saveenv

env_nand.c:saveenv

其调用nand_erase和nand_write进行nand flash的erase、write。nand_write和nand_erase是nand驱动建构。

env在内存中位置不定。env在内存中的空间是由malloc分配的(env_common.c中的env_relocate()),因此其在内存中的位置是一直变化的。每次系统启动时,env在内存中位置可能都不一样。

  1. 环境变量优化

由于u-boot代码通常达到100KB左右,且必须从地址0处开始,按照这样的分配方式(Nandflash结构),我们必须为env分配一块64KB的sector,而实际使用到的可能只是其中几百个字节!u-boot还会为env在RAM中保持一块同样大小的空间,这就造成ROM和RAM空间不必要的浪费。

为了尽可能减少资源浪费,同时保证系统的健壮性,我们可以把env放置在flash中容量最小的sector里。这样,env嵌入(embed)到u-boot的代码段。在common/environment.h中会比较env和monitor的范围,如果确定env位于monitor内,则定义ENV_IS_EMBEDDED。

原文地址:https://www.cnblogs.com/newjiang/p/11865165.html

时间: 2024-08-01 09:55:34

uboot中setenv和saveenv分析的相关文章

S5PV210 uboot中的 MMU代码分析

1:经过上一节的分析,如果采用SECTION虚拟地址映射的话: 程序员只需要做的事情: (1) 建立转换表,Tanslation Table: (2) 将TTB(转换表基地址Tanslation Table Base)写入协处理器CP15的C2寄存器,这里要注意转换表 基地址为16K对齐的(因为4096*32bit=16K)所以TTB的bit0-bit13为0. (3) 使能MMU,将CP15的C1寄存器0bit写1: (4) 设置域的访问权限:设置C3寄存器: CPU/MMU做的事情: (1)

tiny4412 串口驱动分析 --- u-boot中的串口驱动

作者:彭东林 邮箱:[email protected] 开发板:tiny4412ADK+S700 4GB Flash 主机:Wind7 64位 虚拟机:Vmware+Ubuntu12_04 u-boot:U-Boot 2010.12 Linux内核版本:linux-3.0.31 Android版本:android-4.1.2 我们以tiny4412为例分析串口驱动,下面我们从u-boot开始分析,然后再分析到Linux. 串口初始化 关于这部分代码流程参考件:tiny4412 u-boot 启动

uboot移植之start_armboot()函数分析

/******************************** uboot的第二阶段就是初始化剩下的还没在第一阶段初始化的硬件.主要是SoC外部硬件(譬如 iNand 网卡芯片....... )uboot本身的一些东西(uboot的命令 环境变量等.....).然后最终初始化完必要的东西后进入到uboot的命令行准备接受命令. ***********************************/ void start_armboot (void)       //这个函数构成了uboot

u-boot中分区和内核MTD分区关系

一.u-boot中环境变量与uImage中MTD的分区关系 分区只是内核的概念,就是说A-B地址放内核,C-D地址放文件系统,(也就是规定哪个地址区间放内核或者文件系统)等等. 一般我们只需要分3-4个区,第一个为boot区,一个为boot参数区(传递给内核的参数),一个为内核区,一个为文件系统区.(但是有的内核就会有很多分区,比如内核参数会有两个,还有会Logo的地址) 而对于bootloader中只要能将内核下载到A~B区的A地址开始处就可以,C~D区的C起始地址下载文件系统…….这些起始地

u-boot中添加mtdparts支持以及Linux的分区设置

简介 作者:彭东林 邮箱:[email protected] u-boot版本:u-boot-2015.04 Linux版本:Linux-3.14 硬件平台:tq2440, 内存:64M   NandFlash: 256MB 下面我们分两部分,u-boot和kernel,首先介绍u-boot中是如何支持mtdparts的,然后简单分析Linux内核设置分区的两种方式: 方式一 在平台代码中写死,然后在初始化NandFlash的时候设置. 方式二 在u-boot中设置,这个比较灵活,u-boot将

u-boot中链接地址和加载地址的相关知识

以zc702开发板的u-boot为例 链接地址(运行地址):链接地址是在程序编译链接阶段就确定好的地址. u-boot的链接脚本由CONFIG_SYS_LDSCRIPT宏定义来指定,如在zynq_common.h当中有如下代码: #define CONFIG_SYS_LDSCRIPT "arch/arm/cpu/armv7/zynq/u-boot.lds" 在该链接脚本中指定了u-boot中各部分的链接顺序.同时zynq_common.h中的CONFIG_SYS_TEXT_BASE则指

u-boot中的Makefile

在windos下,pc机上电之后,BIOS会初始化硬件配置,为内核传递参数,引导操作系统启动,并且识别C盘.D盘.等整个操作系统启动起来之后,才可以运行应用程序比如QQ.QQ音影.同理,在嵌入式Linux操作系统中,bootloader在上电之后初始化硬件设备,引导Linux内核启动,并且挂在文件系统,等整个操作系统启动之后.运行应用程序.              bootloader其实就是一个单片机程序,一般采用开发的语言是汇编和C语言,但是不同的硬件平台下的boot是不同的.booloa

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

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

uboot移植之start.S分析

uboot的函数入口要查看链接脚本中ENTTRY的入口参数,我们这里的链接脚本在board/samsung/x210/u-boot.lds,这个文件里面的开头有一句ENTRY(_start),所以uboot的入口就是在_start这个标识的地方. * Base codes by scsuh (sc.suh) */ //x210_sd.h对开发板的宏定义配置文件,这个文件会被用来生成一个autoconfig.mk文件,这个文件会被主Makefile引入,指导整个编译过程 #include <con