关于uboot代码所设置的raw分区分析

---

uboot version : 1.3.4
CPU : s5pv210
开发板 : 九鼎x210
分析工具 : Source Insight

---

1. uboot初始化raw分区代码

在学完uboot的大致体系后，我一直有个问题不太清楚，那就是在uboot通过fastboot烧录镜像时所用的分区名究竟在何时定义过，raw分区究竟是怎样安排在iNand（启动介质）中的，带着这些问题，我又从uboot启动第二阶段开始寻找踪迹。想了想，既然环境变量也有分区，那在环境变量重定义代码中必定能找到相应的分区初始化代码，所以以…/uboot/lib_arm/board.c 文件中的start_armboot 函数为起点，找到调用env_relocate 函数的地方，这个函数就是环境变量重定位的函数。进入这个函数的定义处，在删除一些条件编译没有编译的代码后，可以得到如下几行代码：

env_ptr = (env_t *)malloc(CFG_ENV_SIZE);
if (gd->env_valid == 0) {
	puts ("*** Warning - bad CRC, using default environment\n\n");
	set_default_env();
else {
	env_relocate_spec();
}
gd->env_addr = (ulong)&(env_ptr->data);

第一句为全局变量env_ptr分配了一块内存，大小是环境变量分区的大小（这里是16KB），你跳到malloc 函数定义处，可能会发现malloc函数返回值是NULL，其实是SI软件的问题，你只要查看malloc.h 文件就可以发现malloc 函数其实是Dlmalloc.c 文件中的mALLOc 函数的别名，通过宏定义实现。然后由于在第二阶段一开始的初始化函数env_init 中就将gd->env_valid置为1，所以始终会执行env_relocate_spec 函数。跳到env_relocate_spec 函数定义处，可以发现有如下几行代码：

uint *magic = (uint*)(PHYS_SDRAM_1);

if ((0x24564236 != magic[0]) || (0x20764316 != magic[1]))
	movi_read_env(virt_to_phys((ulong)env_ptr));

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

第一个if语句判断PHYS_SDRAM_1内存地址处是否有魔数0x24564236或者PHYS_SDRAM_1+4地址处是否有魔数0x20764316，我们之前并没有填充过这两个区域，所以执行movi_read_env 函数。重点来了，跳入函数定义处，发现一个全局变量raw_area_control，查看其定义如下：

/*
 * magic_number: 0x24564236
 * start_blk: start block number for raw area
 * total_blk: total block number of card
 * next_raw_area: add next raw_area structure
 * description: description for raw_area
 * image: several image that is controlled by raw_area structure
 * by scsuh
 */
typedef struct raw_area {
	uint magic_number; /* to identify itself */
	uint start_blk; /* compare with PT on coherency test */
	uint total_blk;
	uint next_raw_area; /* should be sector number */
	char description[16];
	member_t image[15];
} raw_area_t; /* 512 bytes */

这个结构体里面还套了一个结构体，定义如下：

/*
 *
 * start_blk: start block number for image
 * used_blk: blocks occupied by image
 * size: image size in bytes
 * attribute: attributes of image
 *            0x1: u-boot parted (BL1)
 *            0x2: u-boot (BL2)
 *            0x4: kernel
 *            0x8: root file system
 *            0x10: environment area
 *            0x20: reserved
 * description: description for image
 * by scsuh
 */
typedef struct member {
	uint start_blk;
	uint used_blk;
	uint size;
	uint attribute; /* attribute of image */
	char description[16];
} member_t; /* 32 bytes */

仔细分析，不难得出raw_area_control中的image成员就是每个分区的信息结构体，那究竟在何时初始化了这些结构体呢？通过SI软件的查找功能，可以发现cmd_movi.c 文件中调用过这个全局变量，大致浏览了一下该文件，可以发现第522行到600行在为image结构体赋值信息。这段代码所在的函数是init_raw_area_table 函数，查找该函数的调用处，发现mmc_startup 函数调用过它，同理往前推可以得到mmc_startup >> mmc_init >> mmc_initialize，这样又回到了第二次启动阶段，原来在start_armboot 函数637行初始化SD/MMC时已经初始化了分区表。

2. 分区表

正如前面所说，在…/uboot/common/cmd_movi.c 文件中的init_raw_area_table 函数中可以得到分区表，相关代码如下：

#if defined(CONFIG_EVT1)
	#if defined(CONFIG_FUSED)
		/* image 0 should be fwbl1 */
		image[0].start_blk = (eFUSE_SIZE/MOVI_BLKSIZE);
		image[0].used_blk = MOVI_FWBL1_BLKCNT;
		image[0].size = FWBL1_SIZE;
		image[0].attribute = 0x0;
		strcpy(image[0].description, "fwbl1");
		dbg("fwbl1: %d\n", image[0].start_blk);
	#endif
#endif

		/* image 1 should be bl2 */
#if defined(CONFIG_EVT1)
	#if defined(CONFIG_FUSED)
		image[1].start_blk = image[0].start_blk + MOVI_FWBL1_BLKCNT;
	#else
		image[1].start_blk = (eFUSE_SIZE/MOVI_BLKSIZE);
	#endif
#else
		image[1].start_blk = capacity - (eFUSE_SIZE/MOVI_BLKSIZE) -
				MOVI_BL1_BLKCNT;
#endif
		image[1].used_blk = MOVI_BL1_BLKCNT;
		image[1].size = SS_SIZE;

		image[1].attribute = 0x1;
		
		strcpy(image[1].description, "u-boot parted");
		dbg("bl1: %d\n", image[1].start_blk);

		/* image 2 should be environment */
#if defined(CONFIG_EVT1)
		image[2].start_blk = image[1].start_blk + MOVI_BL1_BLKCNT;
#else
		image[2].start_blk = image[1].start_blk - MOVI_ENV_BLKCNT;
#endif
		image[2].used_blk = MOVI_ENV_BLKCNT;
		image[2].size = CFG_ENV_SIZE;
		image[2].attribute = 0x10;
		strcpy(image[2].description, "environment");
		dbg("env: %d\n", image[2].start_blk);

		/* image 3 should be bl2 */
#if defined(CONFIG_EVT1)
		image[3].start_blk = image[2].start_blk + MOVI_ENV_BLKCNT;
#else
		image[3].start_blk = image[2].start_blk - MOVI_BL2_BLKCNT;
#endif
		image[3].used_blk = MOVI_BL2_BLKCNT;
		image[3].size = PART_SIZE_BL;
		image[3].attribute = 0x2;
		strcpy(image[3].description, "u-boot");
		dbg("bl2: %d\n", image[3].start_blk);

		/* image 4 should be kernel */
#if defined(CONFIG_EVT1)
		image[4].start_blk = image[3].start_blk + MOVI_BL2_BLKCNT;
#else
		image[4].start_blk = image[3].start_blk - MOVI_ZIMAGE_BLKCNT;
#endif
		image[4].used_blk = MOVI_ZIMAGE_BLKCNT;
		image[4].size = PART_SIZE_KERNEL;
		image[4].attribute = 0x4;
		strcpy(image[4].description, "kernel");
		dbg("knl: %d\n", image[4].start_blk);

		/* image 5 should be RFS */
#if defined(CONFIG_EVT1)
		image[5].start_blk = image[4].start_blk + MOVI_ZIMAGE_BLKCNT;
#else
		image[5].start_blk = image[4].start_blk - MOVI_ROOTFS_BLKCNT;
#endif
		image[5].used_blk = MOVI_ROOTFS_BLKCNT;
		image[5].size = PART_SIZE_ROOTFS;
		image[5].attribute = 0x8;
		strcpy(image[5].description, "rfs");
		dbg("rfs: %d\n", image[5].start_blk);

由于CONFIG_FUSED 宏没有定义，故总共5个分区，分析如下：

扇区号	分区名	大小
1-16	BL1	8KB
17-48	environment	16KB
49-1072	BL2	512KB
1073-9264	kernel	4MB
9265-62512	rootfs	26MB

3. 验证分析的正确性

我们可以用环境变量分区做个小测试验证我们分析的正确性。

---

(1). 在do_printenv 函数的最后一句return rcode;之前添加一句movi_write(17,32, 0xE0000000);，movi_write 函数用于向iNand写数据，17是起始扇区号，32是扇区数，0xE0000000是随便找的一块可读的内存区的起始地址，这句话主要是为了破坏环境变量分区。
(2). 分析env_relocate_spec 函数，由于破坏了环境变量分区，CRC校验必然失败肯定会执行use_default 函数，而这个函数第一句代码是puts ("*** Warning - bad CRC or moviNAND, using default environment\n\n");代码，所以在uboot的shell下输入printenv命令（printenv命令执行的函数就是do_printenv），就会执行movi_write(17,32, 0xE0000000);，破坏环境变量分区。最后重启uboot，会发现puts的字符串。
(3). 按照(1)修改好后，重新编译下载启动，输入printenv，关机重启，会出现下图：

如果你这时saveenv后会还原环境变量分区，开机重启后，划线句不会出现。有兴趣可以尝试一下。