1、启动u-boot 跳转到内核的时报错:
Wrong Ramdisk Image Format [err] boot_get_ramdisk
然后就卡死了……
2、启动 u-boot 跳转到内核时报错:
Wrong Ramdisk Image Format [err] boot_get_ramdisk Starting kernel ... Uncompressing Linux... done, booting the kernel.
然后卡死……
根据报错的信息定位到u-boot 源码:
common/image.c --> boot_get_ramdisk():通过读取ramdisk.img 的Image Header Magic Number来确定ramdisk的格式;该函数在do_bootm_linux()函数中被调用。
那么ramdisk.img 是存在哪个位置的呢?我在此之前并没有烧录ramdisk的镜像,它怎么会存在呢?
在u-boo跳转到加载内核的过程中有这样的一些打印信息:
reading RFS.. 11360, 2048 MMC read: dev # 0, block # 11360, count 2048 ...2048 blocks read: OK
意思是从MMC设备0(这里表示的eMMC) 的第11360块开始读取,连续读取2048 块,这里ramdisk 镜像的起始块是不是固定的呢?答案是否定的,为什么呢?看一下烧录厂家提供的u-boot镜像的启动信息,看到读取ramdisk镜像的起始块是不一样的:
reading RFS.. 13408, 2048 MMC read: dev # 0, block # 13408, count 2048 ...2048 blocks read: OK
那么ramdisk镜像的起始块的位置是怎么来的?随机的吗?不是的,在common/cmd_movi.c –> init_raw_area_table,该函数在u-boot启动初始化MMC时被调用:start_armboot –> mmc_initialize –> mmc_init –> mmc_startup –>init_raw_area_table;用于在u-boot启动后在MMC中创建一个分区表;函数中就给出ramdisk起始块的计算方式:
image[5].start_blk = image[4].start_blk + image[4].used_blk;image[5].used_blk = MOVI_ROOTFS_BLKCNT;image[5].size = PART_SIZE_ROOTFS;image[5].attribute = 0x8;strcpy(image[5].description, "ramdisk");
由此ramdisk被烧录到kernel分区结束的第一个块,因此会根据kernel分区大小的变化而改变。对比了厂家提供的u-boot源码和使用的源码中kernel分区的配置,发现前者设置为6M,而后者设置为4M(include/movi.h):
前者:#define PART_SIZE_KERNEL (6 * 1024 * 1024) 后者:#define PART_SIZE_KERNEL (4 * 1024 * 1024)
由此可以推测出现在这份u-boot中配置的ramdisk镜像的起始块并不是烧录在eMMC中ramdisk 的起始地址。那么要怎么解决这个问题呢?这里使用两种方式:
1、修改现有u-boot中给kernel分区配置的大小与厂家的一致,均为6M
2、直接重新烧录ramdisk镜像
至于eMMC中为什么会存在ramdisk镜像,那是因为之前厂家已烧录过,而现在并未破坏原ramdisk镜像所在的块,因此数据仍然可用。
通过问题1的解决思路,可以解决问题2的部分错误,那么为什么已经加载了内核,并且已经成功解压了,为什么就挂掉了呢?是机器码的问题吗?
使用的内核镜像在厂家提供的u-boot中是可以正常启动的,而u-boot中并没有重新修改机器码,因此可以暂时先排除是kernel 镜像的问题。那么问题出在哪里呢?查看kernel 的烧录信息,可以看到:
reading /sdupdate/zImage4292380 (0x00417f1c) bytes read
可以看到zImage的大小要大于4M(4194304bytes),而在问题1中提到过现有的u-boot中给kernel分区配置的大小只有4M,而在烧录和读取内核时的kernel分区的大小是被写死的,因此会造成内核的不完整。因此需要将u-boot中kernel分区的大小分配大于等于zImage的大小,并且为512byte的整数倍。之后还要重新烧录zImage 和ramdisk 镜像。
联系客服