Dm37xx android2.3.4 added the recovery upgrade function (2) -- debugging

Reprinted, please indicate the source and author of the article!

Source: http://blog.csdn.net/xl19862005

By xandy)

In the previous article, I briefly explained the code modification part involved in adding the recovery function. After the code is modified successfully, it is not equal to the required function, there are still a lot of problems to solve after compilation is completed to the target board!

After one day of hard work, Bootloader and recovery are added and compiled successfully. After being installed on the prototype, the first thing to verify is whether the bootcmd switch is normal. Here, the bootcmd switch for testing is added, marked in red as follows:

# Define config_extra_env_settings \
"Loadaddr = 0x82000000 \ 0 "\
"Nandboot = echo booting from NAND ...;"\
"NAND read $ {loadaddr} 280000 500000; bootm $ {loadaddr} \ 0 "\
"Bootcmd = run nandboot \ 0 "\
"Bootargs = init =/init console = ttyo2, 115200n8 IP = OFF "\
"Androidboot. Console = ttyo2 mem = 512 m rw ubi. MTD = 6, 2048 "\
"Rootfstype = ubifs root = ubi0: rootfs rootdelay = 2 "\
"Omapdss. def_disp = LCD "\
"VRAM = 8 m omapfb. VRAM = 0: 8 m mpurate = 1000 \ 0 "\
"Android_recovery_switch = 1 \ 0"

It should be noted that the modified bootcmd will not work after the uboot is modified and compiled and burned to the prototype, the reason is that during uboot, uboot is burned to the corresponding uboot partition, while bootcmd and these system startup parameters are stored in the uboot-env partition, you can see it in the partition list in the previous article!

For more information about how to burn an image file to a specified partition, we can use the flash v1.x burning tool provided by TI, or use fastboot or other methods, fastboot batch processing is used here!

So how can we make the new bootcmd take effect?

Nand erase

This command can erase the content in the corresponding partition, but note that if you directly enter the NAND erase and press enter, your entire NAND space will be cleared, including xloader and uboot! What if I want to erase the specified partition?

You need to mention that in uboot, there is a default partition list similar to the following in config:

# Define mtdparts_default "mtdparts = NAND: 512 K (xloader ),"\
"1920 K (uboot ),"\
"128 K (ubootenv ),"\
"5 m (kernel ),"\
"1 m (cache ),"\
"100 m (recovery ),"\
"256 m (system )"

You only need to enter a simple command in the uboot command line:

Mtdparts default

Then run NAND erase XX. Here, XX can be the partition code in mtdparts, as shown in

Nand erase ubootenv

In this way, the corresponding partition space can be erased!

After the system is started, the kernel is loaded normally and various ubi parameters are parsed, but the following error may occur:

[1.675323] omap2-nand driver initializing
[1.679931] NAND device: Manufacturer ID: 0xad, chip ID: 0xbc (Hynix)
[1.686767] creating 7 MTD partitions on "omap2-nand.0 ":
[1.692321] 0x000000000000-0x000000020000: "X-loader"
[1.698944] 0x000000080000-0x000000240000: "U-Boot"
[1.705902] 0x000000260000-0x0000002a0000: "U-boot env"
[1.712554] 0x000000280000-0x000000780000: "kernel"
[1.720794] 0x000000780000-0x000000880000: "cache"
[1.727325] 0x000000880000-0x000006c80000: "recovery"
[1.774688] 0x000006c80000-0x000020000000: "File System"
[2, 1.946777] onenand driver initializing
[2, 1.951416] ubi: attaching mtd5 to ubi0
[1.955413] ubi: Physical eraseblock size: 131072 bytes (128 kib)
[1.961944] ubi: Logical eraseblock size: 129024 bytes
[1.967590] ubi: smallest flash I/O unit: 2048
[1, 1.972473] ubi: Sub-page size: 512
[1.977294] ubi: vid header offset: 512 (aligned 512)
[1.983367] ubi: Data offset: 2048
[1.988586] ubi error: validate_ec_hdr: Bad vid header offset 2048, expected 512
[2, 1.996276] ubi error: validate_ec_hdr: Bad EC Header
[2.001556] ubi error: ubi_io_read_ec_hdr: Validation failed for peb 0
[2.008392] ubi error: ubi_init: cannot attach mtd5

This is because the parameter is incorrect when the ubi file image is created. The error message is that the vid header offset is incorrect. Follow the prompts here to change the vid header offset parameter to 512.

The following red string:

Ubinize-o $ {out_image_path}/recovery. IMG-M 2048-P 128kib-s 512-O 512 reubinize. cfg

For instructions on these parameters, enter ubinize-H in Ubuntu to view the instructions (provided that you have downloaded and compiled and installed MTD-ubifs)

After re-creating the file image and burning it to the sub-host, the following information appears:

[1.688598] omap2-nand driver initializing
[1.693206] NAND device: Manufacturer ID: 0xad, chip ID: 0xbc (Hynix)
[1.700042] creating 7 MTD partitions on "omap2-nand.0 ":
[1.705566] 0x000000000000-0x000000020000: "X-loader"
[1.712219] 0x000000080000-0x000000240000: "U-Boot"
[1.719177] 0x000000260000-0x0000002a0000: "U-boot env"
[1.725799] 0x000000280000-0x000000780000: "kernel"
[1.734039] 0x000000780000-0x000000880000: "cache"
[1.740570] 0x000000880000-0x000006c80000: "recovery"
[1.787994] 0x000006c80000-0x000020000000: "File System"
[2, 1.960144] onenand driver initializ
[2, 1.964782] ubi: attaching mtd5 to ubi0
[1.968780] ubi: Physical eraseblock size: 131072 bytes (128 kib)
[1.975372] ubi: Logical eraseblock size: 129024 bytes
[1.980987] ubi: smallest flash I/O unit: 2048
[1, 1.985870] ubi: Sub-page size: 512
[1.990692] ubi: vid header offset: 512 (aligned 512)
[1.996765] ubi: Data offset: 2048
[1, 2.167388] ubi: Max. Sequence Number: 0
[2.187500] ubi: volume 0 ("rootfs") re-sized from 773 to 788 lebs
[2, 2.194702] ubi: attached mtd5 to ubi0
[2, 2.198638] ubi: MTD device name: "recovery"
[2.204071] ubi: MTD device size: 100 MIB
[2.209259] ubi: Number of good pebs: 800
[1, 2.214050] ubi: Number of bad pebs: 0
[2.218688] ubi: number of parallel upted pebs: 0
[2.223297] ubi: Max. Allowed volumes: 128
[2.228118] ubi: Wear-leveling threshold: 4096
[1, 2.233001] ubi: number of internal volumes: 1
[2.237640] ubi: number of user volumes: 1
[1, 2.242248] ubi: available pebs: 0
[2.246887] ubi: Total number of reserved pebs: 800
[2.251983] ubi: Number of pebs reserved for bad peb handling: 8
[2.258209] ubi: Max/mean erase counter: 1/0
[2.262664] ubi: Image Sequence Number: 34986596
[2.267639] ubi: Background thread "ubi_bgt0d" started, PID 563

We can see that the ubi resolution is normal, and the following will go to ubifs, the following information appears:

[7.308471] ubifs error (PID 1): validate_sb: LEB size mismatch: 126976 in superblock, 129024 real
[1, 7.317840] ubifs error (PID 1): validate_sb: Bad superblock, error 1
[7.326354] list of all partitions:
[7.330047] 1f00 128 mtdblock0 (driver ?)
[7.335296] 1f01 1792 mtdblock1 (driver ?)
[7.340576] 1f02 256 mtdblock2 (driver ?)
[7.345855] 1f03 5120 mtdblock3 (driver ?)
[7.351104] 1f04 1024 mtdblock4 (driver ?)
[7.356384] 1f05 102400 mtdblock5 (driver ?)
[7.361663] 1f06 413184 mtdblock6 (driver ?)
[7.366912] b3003872256 mmcblk0 DRIVER: mmcblk
[7.372467] b301 3871232 mmcblk0p1 00000000-0000-0000-0000-0000000000000000mmcblk0p1
[7.381072] No filesystem cocould Mount root, tried: ubifs

According to the information, we can see that there was a problem when creating the ubifs file image. Here we are prompted that there was a problem with the superblock, And the LEB size mismatch !!

LEB size mismatch continue input mkfs. ubifs-h under Ubuntu to view help, as shown below:

-E, -- LEB-size = size logical erase block size

This is the-e parameter. Follow the prompts here to change the previous 126976 to 129024. The last is as follows:

Mkfs. ubifs-r $ {recovery_rootfs}-f-o ubifs. IMG-M 2048-e 129024-C 788

The file ubifs. cfg and the confirmation of the-C parameter are also worth noting.

For example, the ubifs. cfg file of my corresponding recovery is as follows:

[Ubifs]
Mode = ubi
Image = ubifs. img
Vol_id = 0
Vol_size = 95mib
Vol_type = dynamic
Vol_name = rootfs
Vol_flags = autoresize

Note that the above red string

The calculation of these values is as follows:

Usable Size Calculation

As incluented here, ubi reserves a certain amount
Of space for management and bad peb handling operations. Specifically:

• 2 pebs are used to store the ubi volume table
• 1 peb is reserved for Wear-leveling purposes;
• 1 peb is reserved for the atomic LEB change operation;
• A % of pebs is reserved for handling bad EBS. The default for NAND is 1%
• UBI stores the erase counter (EC) and volume ID (VID) headers at the beginning of each peb. 1 min I/O unit is required for each of these.

To calculate the full overhead, we need the following values:

Symbol	Meaning	Value for XO test case
SP	Peb size	128kib
SL	LEB size	128kib-2 * 2kib = 124 kib
P	Total number of pebs on the MTD Device	100mib/128kib = 800
B	Number of pebs reserved for bad peb handling	1% of P = 8
O	The overhead related to storing EC and vid headers in bytes, I. e. o = Sp-SL	4kib

UBI overhead = (B + 4) * SP + O * (p-B-4) = (8 + 4) * 128kib + 4 kib * (800-8-4) = 4688 kib = 36.625 pebs (take an integer of 36)

This leaves us with 800-36 = 764 pebs or 97792kib available for user data.

Note that we used "-C 788" in the above mkfs. ubifs command line to specify the maximum filesystem size, not "-C 764" the reason for this is that mkfs. ubifs operates in terms of Leb size (124 kib), not peb size (128kib ). 97792kib/124 kib = 788. 645... (Take an integer of 788 ).

Volume size = 97792kib (~ 95mib)

The reason why I set the recovery partition to 100mib is that the value of P must be greater than or equal to 1% if the value of B is 100 * P, 100 * 128kib = 12.5mib, because my NAND is 512mib, I simply set the recovery partition to 100mib (taking into account Bad blocks and other issues)

After the above ups and downs, re-burn the recovery file image. After the system restarts, haha, see:

But soon I found the problem. The first time I enter the recovery status, it is OK. When I enter again after power failure and restart, the following error will occur:

[2, 1.754913] ubi: attaching mtd4 to ubi0
[1.759155] ubi: Physical eraseblock size: 131072 bytes (128 kib)
[1.765625] ubi: Logical eraseblock size: 129024 bytes
[1.771301] ubi: smallest flash I/O unit: 2048
[1, 1.776214] ubi: Sub-page size: 512
[1.780975] ubi: vid header offset: 512 (aligned 512)
[1.787078] ubi: Data offset: 2048
[1.794128] ubi error: ubi_io_read: Error-74 (ECC error) while reading 64 bytes from peb, read 64 bytes
[1.804473] [<c00a3678>] (unwind_backtrace + 0x0/0xec) from [<c02be868>] (ubi_io_read + 0x1b4/0x248)
[1.813659] [<c02be868>] (ubi_io_read + 0x1b4/0x248) from [<c02bee1c>] (ubi_io_read_ec_hdr + 0x6c/0x338)
[1.823242] [<c02bee1c>] (ubi_io_read_ec_hdr + 0x6c/0x338) from [<c02c24f0>] (ubi_scan + 0x1b4/0xb9c)
[1.832489] [<c02c24f0>] (ubi_scan + 0x1b4/0xb9c) from [<c02b9624>]

The error message indicates that an error occurs in ECC, but hwecc is used here. How can this error be reported?

Google once and found the cause of the problem in the following blog:

Http://blog.csdn.net/lidehua1975/article/details/7768185

Modify according to the method here, where the first initialization of options is in arch/ARM/mach-omap2/board-xx.c

In the zt6810_flash_init Function

Static void _ init zt6810_flash_init (void)

{

......

......

Nand_no_subpage_write if (nandcs <gpmc_cs_num ){
Printk (kern_info "registering NAND on CS % d \ n", nandcs );
Board_nand_init (zt6810_nand_partitions, array_size (zt6810_nand_partitions), nandcs, nand_buswidth_16 | nand_no_subpage_write); // modify
By xandy, no subpage write

}

}

After compiling the kernel, enter the recovery mode again. The following information is displayed:

[7.308471] ubifs error (PID 1): validate_sb: LEB size mismatch: 129024 in superblock, 126976 real
[1, 7.317840] ubifs error (PID 1): validate_sb: Bad superblock, error 1
[7.326354] list of all partitions:
[7.330047] 1f00 128 mtdblock0 (driver ?)
[7.335296] 1f01 1792 mtdblock1 (driver ?)
[7.340576] 1f02 256 mtdblock2 (driver ?)
[7.345855] 1f03 5120 mtdblock3 (driver ?)
[7.351104] 1f04 1024 mtdblock4 (driver ?)
[7.356384] 1f05 102400 mtdblock5 (driver ?)
[7.361663] 1f06 413184 mtdblock6 (driver ?)
[7.366912] b3003872256 mmcblk0 DRIVER: mmcblk
[7.372467] b301 3871232 mmcblk0p1 00000000-0000-0000-0000-0000000000000000mmcblk0p1
[7.381072] No filesystem cocould Mount root, tried: ubifs

Hey, change the parameters for creating the recovery file image back to the previous ones:

Mkfs. ubifs-r $ {recovery_rootfs}-f-o ubifs. IMG-M 2048-e126976-C 788

If you burn and run the program, you will not see the above problems again!

It's really just a tug of war !!

At present, the recovery system has been loaded normally, but there are still some problems, such as the cache partition not being mounted as prompted in, this is free and then the problem of modifying the partition mounting under recovery.