Problems encountered during U-Boot porting

Linux general technology-Linux programming and kernel information-problems encountered during U-Boot porting. The following is a detailed description. Due to the fact that I did not program my ARM embedded system as planned during the summer vacation, I have not started my graduation thesis recently. I have to port U-Boot and Linux to my Development Board QQ2440V3, which has always encountered various problems, here, we will announce some valuable references for later users.

Question 1: "soft floating point"

Compile U-Boot with arm-linux-gcc-3.4.1 appears:

/Home/peng/toolchain/3.4.1/bin/arm-linux-ld: ERROR:/home/peng/toolchain/3.4.1/bin /.. /lib/gcc/arm-linux/3.4.1/libgcc. a (_ udivdi3. OS) uses hardware FP, whereas u-boot uses software FP
/Home/peng/toolchain/3.4.1/bin/arm-linux-ld: failed to merge target specific data of file/home/peng/toolchain/3.4.1/bin /.. /lib/gcc/arm-linux/3.4.1/libgcc. a (_ udivdi3. OS)
/Home/peng/toolchain/3.4.1/bin/arm-linux-ld: ERROR:/home/peng/toolchain/3.4.1/bin /.. /lib/gcc/arm-linux/3.4.1/libgcc. a (_ clz. OS) uses hardware FP, whereas u-boot uses software FP
/Home/peng/toolchain/3.4.1/bin/arm-linux-ld: failed to merge target specific data of file/home/peng/toolchain/3.4.1/bin /.. /lib/gcc/arm-linux/3.4.1/libgcc. a (_ clz. OS)

I heard that the cross compiler below 3.3.2 for compiling U-Boot is still prone to FP problems under 3.3.2:

/Home/peng/toolchain/3.3.2/bin/arm-linux-ld: Error:/home/peng/toolchain/3.3.2/bin /.. /lib/gcc-lib/arm-linux/3.3.2/libgcc. a (_ udivdi3. OS) uses hardware FP, while u-boot uses software FP.
File Format error: failed to merge target specific data of file/home/peng/toolchain/3.3.2/bin /.. /lib/gcc-lib/arm-linux/3.3.2/libgcc. a (_ udivdi3. OS)
/Home/peng/toolchain/3.3.2/bin/arm-linux-ld: Error:/home/peng/toolchain/3.3.2/bin /.. /lib/gcc-lib/arm-linux/3.3.2/libgcc. a (_ clz. OS) uses hardware FP, while u-boot uses software FP.
File Format error: failed to merge target specific data of file/home/peng/toolchain/3.3.2/bin /.. /lib/gcc-lib/arm-linux/3.3.2/libgcc. a (_ clz. OS)
Make: *** [u-boot] Error 1

I checked a lot of information and found that using arm-softfloat-linux-gnu and arm-linux-gcc-3.4.5-glibc-2.3.6 compilation can solve the above "soft floating point" problem.

Problem 2: Incorrect CRC
After compiling the compiled U-Boot image file with H-Jtag and writing it into NOR Flash, the following error always occurs after powering on the Development Board: Warning-bad CRC, using default environment

At first, I thought it was because the NOR Flash used by the Development Board was 29lv160DB, while the templates used 29lv800BB and 29lv400BB, which were my porting problems. After reading and analyzing the corresponding flash. c file and the corresponding board header file, it is found that there is no problem with porting. I checked it on the Internet and found that it was because the new environment parameters were not manually set when U-Boot was run for the first time, but the environment parameters have been set in the source file during the porting process. Whether or not the environment parameters are set during the migration process, you must set a parameter for the first operation. Otherwise, U-Boot will use the parameters set during the migration process (this parameter is the default parameter, default environment) and prompt Warning-bad CRC, using default environment.

Problem 3: ** Read Error and Bad Magic Number problems when loading the kernel to the memory

After writing the kernel to Nand Flash, start the Development Board and wait for prompts:

Loading from NAND 64MiB, 3 V 8-bit, offset 0x0
** Read error
# Booting image at 31000000...
Bad Magic Number

This problem occurs when you use the uImage generated by the cross compiler make uImage and the mkimage tool under U-Boot to make zImage. I thought it was a problem with the NAND Flash Driver and related read functions during the U-Boot transplantation. Later I found that the default parameter "nboot 0x31000000 0 0" in the source file was modified; bootm 0x3000000 "is" NAND read. jffs2 0x31000000 0x0 0x1E0000; bootm 0x3000000 "will be able to start the kernel, without the ** Read Error and Bad Magic Number prompts, but a lot more Read information. I still want to use "nboot 0x31000000 0 0; bootm 0x3000000" to start loading and starting the kernel. For this problem, I have been tossing for two days, but I still have no results. Later, I posted my questions on the Internet to the author of the book embedded Linux application development full manual. I learned that nboot cannot skip Bad blocks because there are bad blocks in the kernel storage zone of NAND Flash, read. jffs2 can skip the bad block of NAND Flash. It seems that I am blind enough to solve the above ** Read Error and Bad Magic Number problems.

The above three problems consume more than a week, and the cost is too high.

Author: Liang fupeng

Source: http://blog.sina.com.cn/s/blog_548d39f90100ar06.html