Note 2416 some problems encountered when porting the 2.6.36 kernel and the yaffs root file system

 

Note the problems encountered when porting the 2.6.36 kernel and the yaffs File System on MySQL 2416

 

References:
Http://blog.sina.com.cn/s/blog_77aea4c60100qsa1.html

1. After the kernel uimage is burned into NAND flash in uboot, the following error is reported when the kernel is started:

# Booting kernel from legacy image at 30008000...

Image name: Linux-2.6.36

Created: 2011-01-21 2:28:54 UTC

Image Type: ARM Linux kernel image (uncompressed)

Data size: 2799972 bytes = 2.7 MIB

Load address: 30008000

Entry Point: 30008000

Verifying checksum... OK

Xip kernel image... OK

OK

Starting kernel...

Data abort

PC: [<30008008>] LR: [<33f23fa4>]

SP: 33dffb50 IP: 00000000 FP: 30008000

R10: 33f4603c R9: 00000695 R8: 33dfffe0

R7: 33dfffc4 R6: 33e01355 R5: 30000124 R4: 00000000

R3: 00000000 R2: 30000100 r1: 00000695 R0: 00000000

Flags: nzcv irqs off fiqs off mode svc_32

Resetting CPU...

Analysis:

It may be caused by the same load address: 30008000 and entry point: 30008000.

Solution: Re-compile the kernel

Make zimage;

Mkimage-A arm-O Linux-T kernel-C none-A 30008000-e 30008040-n "linux-2.6.36"-D./ARCH/ARM/boot/zimage uimage

Mkimage adds an information header to zimage to generate uimage

-The architecture of a arm is arm.

-O the Linux operating system is Linux

-T the kernel type is kernel.

-C none: the compression type is non-compression.

-A 30008000 image loading address (HEX)

-E 30008040 kernel entry address (HEX), because the size of the Information header is 0x40

-N linux-2.6.36 image name

-D: image file name with no header information in zimage

The image file name after the uimage header information is added

2. Run the write command under uboot. yaffs 30000000 500000 1080840, the tool mkyaffs2image in yaffs2/utils will be used. the file system image generated by C is burned to the NAND Flash. After the reset is restarted, the following error occurs:

[0.680000] NAND device: Manufacturer ID: 0xad, chip ID: 0xf1 (Hynix NAND 128mib, 3 V 8-bit)

[0.685000] scanning device for Bad blocks

[0.695000] Bad eraseblock 41 at 0x000000520000

[0.695000] Bad eraseblock 42 at 0x000000540000

............ A lot of bad eraseblock ............

[2.025000] Bad eraseblock 441 at 0x000003720000

[2.030000] Bad eraseblock 442 at 0x000003740000

[2.080000] creating 4 MTD partitions on "NAND ":

[2.080000] 0x000000000000-0x000000100000: "U-Boot"

[2.090000] 0x000000100000-0x000000500000: "kernel"

[2.095000] 0x000000500000-0x000002500000: "rootfs"

[2.100000] 0x000002500000-0x000008000000: "work"

Analysis:

When so many bad eraseblocks occur, it is impossible for a good NAND Flash to suddenly have so many bad blocks. It should be because the software mistakenly believes that the bad blocks.

In NAND Flash (large page 2 K + 64 B), each page has 64 bytes of spare data, which is used to record information such as ECC checksum and Bad blocks, it is likely that mkyaffs2image mistakenly writes the block status byte bad block flag as a bad block. In 64 bytes spare data, 00th byte (offset = 00) is the block status byte bad block flag, 01st byte is retained, 0x02 bytes to 0x27 bytes a total of 38 bytes are used to store other information (oobfree), 0x28 ~ 0x3f stores ECC verification, which is reflected in the structure yaffs_extendedtags.

If any one of the 00th bytes is 0, it is considered as a bad block. The problem is likely to occur here. Looking back at the write_chunk function in mkyaffs2image. C, we find that it will change 0x02 ~ The content of 0x27byte is written to the place where 0x00byte starts. Therefore, you need to move two digits later, start from 0x02, re-create the file system, and run the NAND scrub kernel command under uboot to delete all the elements, and then run the "OK" command.

References:

Http://blog.csdn.net/pottichu/archive/2009/07/23/4372593.aspx

Http://topic.csdn.net/u/20100225/09/dd14d827-e92a-46ed-b4ad-c5a9f4b90a65.html

3. An error is reported when kernel and file system are transplanted:

[0.895000] yaffs: Dev is 32505858 name is "mtdblock2" RW

[2, 0.900000] yaffs: passed flags ""

[2, 1.380000] VFS: mounted root (yaffs2 filesystem) on device 31: 2.

[2, 1.380000] devtmpfs: mounted

[1.385000] freeing init memory: 160 K

[1.385000] failed to execute/linuxrc. Attempting defaults...

[2, 1.400000] Kernel panic-not syncing: No init found. Try passing init = option to kernel.

See Linux documentation/init.txt for guidance.

[1.405000] [<c0037314>] (unwind_backtrace + 0x0/0xfc) from [<c0034f18>] (dump_stack + 0x1c/0x20)

Analysis:

1. There may be a problem with the/linuxrc file; 2. What I encounter is: first in the kernel source code Drivers/MTD/NAND/S3C2410. in the C function s3c2410_nand_init_chip, convert chip-> ECC. mode = nand_ecc_soft; changed to chip-> ECC. mode = nand_ecc_none; then disable Samsung s3c NAND hardware ECC in Kernel configuration make menuconfig

In this way, no ECC is performed when the kernel reads data from NAND Flash. The following warning is reported when the kernel is started:

[0.695000] nand_ecc_none selected by board driver. This is not recommended !!

4. After the kernel and file system are transplanted, execute the upper-layer application under the shell command line and report the segmentation fault segment error.

Analysis:

1. Generally, segmentation fault segment error is caused by application problems, summary of such errors, the previous article on the net is very classic (Author: zx_wing (xing5820@163.com )), from Baidu Library: http://wenku.baidu.com/view/8ea6f500bed5b9f3f90f1cb9.html

2. In actual situations, the application runs well in the NFS root file system (before transplantation). This is the case after transplantation, and I always thought it was an application problem, after several days of application debugging, I finally suspected that the library was replaced by the cross compiler during the porting process, but the library was not changed. After the library was changed, use the same cross compiler to compile the application again.

So be careful! If you are careful, there will be fewer detours.

5. After the kernel and file system have been installed in NAND, an error is reported during startup:

[2, 1.690000] VFS: mounted root (yaffs2 filesystem) on device 31: 2.

[2, 1.690000] devtmpfs: mounted

[1.695000] freeing init memory: 152 K

/Linuxrc:/lib/libc. so.6: Version 'glibc _ 100' not found (required by/linuxrc)

/Linuxrc:/lib/libc. so.6: Version 'glibc _ 100' not found (required by/linuxrc)

/Linuxrc:/lib/libc. so.6: Version 'glibc _ 100' not found (required by/linuxrc)

[2, 1.890000] Kernel panic-not syncing: attempted to kill Init!

Analysis:

The error indicates that the root file system has been successfully mounted. An error occurred while initializing init =/linuxrc. It is likely that libc does not exist in/lib. so.6 or the libraries are different because of the replacement of cross-compilation.

Solution:

1. Confirm that libc. so.6 exists in/lib;

2. If libc. so.6 is not found or cannot be found at the moment, you can make libc. so.6 soft link to libc. So;

3. If not, replace the entire/lib library. The library should be consistent with your cross compiler.

Appendix: write_chunk function of mkyaffs2image. c

Reference http://blog.csdn.net/itismine/archive/2009/11/11/4799770.aspx

Itismine "mkyaffs2image tool parsing"

Static int write_chunk (_ u8 * data, _ u32 objid, _ u32 chunkid, _ u32 nbytes)

{

Yaffs_extendedtags T;

Yaffs_packedtags2 pt;

/* ------------------------- Change ------------------------------*/

_ U8 spare_buf [sparesize];

Memset (spare_buf, 0, sparesize );/**/

/*---------------------*/

Error = write (OUTFILE, Data, chunksize );

If (error <0) return error;

Yaffs_initialisetags (& T );

T. chunkid = chunkid;

// T. serialnumber = 0;

T. serialnumber = 1; // ** check **

T. bytecount = nbytes;

T. objectid = objid;

T. sequencenumber = yaffs_lowest_sequence_number;

// Added NCB ** check **

T. chunkused = 1;

If (convert_endian)

{

Little_to_big_endian (& T );

}

Yaffs_packtags2 (& PT, & T, 1 );

/* ----------------------- Change --------------------------------*/

Memset (spare_buf, 0xff, sizeof (spare_buf);/* 00byte must be 0xff, which indicates a good block */

Nand_mtd2_pt2buf (spare_buf, & pt);/* Copy Data to spare_buf according to oob_layout */

Yaffs_putdataecc (data, & spare_buf [0]);/* recalculate ECC */

/*---------------------*/

Npages ++;

// Return write (OUTFILE, & PT, sizeof (yaffs_packedtags2 ));

Return write (OUTFILE, spare_buf, sparesize );

}