Problems with porting u-boot (kernel is ported, available):
1. Start u-boot When you jump to the kernel, you get an error:
Wrong Ramdisk Image Format [err] boot_get_ramdisk
Then it is stuck...
2, start u-boot error when jumping to the kernel:
Wrong Ramdisk Image Format [err] boot_get_ramdisk Starting kernel ... Uncompressing Linux... done, booting the kernel.
According to the error message, locate the u-boot source code:
Common/image.c --> boot_get_ramdisk(): by reading ramdisk.imgImage Header Magic Number to determine The format of the ramdisk; this function is called in the do_bootm_linux() function.
So where is ramdisk.img located? I did not burn the image of the ramdisk before this. How could it exist? In the process of u-boo jumping to the loading kernel, there are some printing information like this:
reading RFS.. 11360, 2048 MMC read: dev # 0, block # 11360, count 2048 ...2048 blocks read: OK
This means that reading from the 11360th block of MMC device 0 (eMMC shown here) reads 2048 blocks continuously. Is the starting block of the ramdisk image fixed here? The answer is no, why? Look at the boot information of the u-boot image provided by the manufacturer, and see that the starting block for reading the ramdisk image is different:
reading RFS.. 13408, 2048 MMC read: dev # 0, block # 13408, count 2048 ...2048 blocks read: OK
So how is the location of the starting block of the ramdisk image coming from? Random? No, in common/cmd_movi.c –> init_raw_area_table, this function is called when u-boot starts initializing MMC: start_armboot –> mmc_initialize –> mmc_init –> mmc_startup –> init_raw_area_table; used in MMC after u-boot starts Create a partition table; the function gives the calculation method of the ramdisk start block:
image.start_blk = image.start_blk + image.used_blk; image.used_blk = MOVI_ROOTFS_BLKCNT; image.size = PART_SIZE_ROOTFS; image.attribute = 0x8; strcpy(image.description, "ramdisk");
The ramdisk is then burned to the first block at the end of the kernel partition, so it will change depending on the size of the kernel partition. Comparing the u-boot source code provided by the manufacturer and the configuration of the kernel partition used in the source code, it is found that the former is set to 6M, and the latter is set to 4M (include/movi.h):
former:#define PART_SIZE_KERNEL (6 * 1024 * 1024) The latter:#define PART_SIZE_KERNEL (4 * 1024 * 1024)
It can be speculated that the starting block of the ramdisk image configured in this u-boot is not the starting address of the ramdisk in the eMMC. So how do you solve this problem? There are two ways to do this: 1. Modify the size of the kernel configuration configured in the existing u-boot to be consistent with the manufacturer. Both are 6M. 2, directly re-burn ramdisk image As for why there is a ramdisk image in eMMC, it is because the manufacturer has burned it before, and now the block where the original ramdisk image is located is not destroyed, so the data is still available.
Through the solution of the problem 1, you can solve some of the errors in the problem 2, then why has the kernel been loaded, and has been successfully decompressed, why hang it? Is it a problem with machine code? The kernel image used can be started normally in the u-boot provided by the manufacturer, and the machine code is not re-modified in the u-boot, so it is possible to temporarily exclude the problem of the kernel image. So where is the problem? Looking at the burning information of the kernel, you can see:
reading /sdupdate/zImage 4292380 (0x00417f1c) bytes read
You can see that the size of zImage is larger than 4M (4194304bytes). In question 1, the size of the kernel partition configured in the existing u-boot is only 4M, and the kernel partition is used when burning and reading the kernel. The size is written to death, thus causing the kernel to be incomplete. Therefore, the size of the kernel partition in the u-boot needs to be greater than or equal to the size of the zImage, and is an integer multiple of 512 bytes. Then re-burn the zImage and ramdisk images.