This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

UBIFS error when reflashing

Hi All,

We are using DM8148 based in our product. For out rigorous testing we need to reflash board many times. Where we are using UBIFS to flash our board. We get below errors when we boot the board.

UBIFS error (pid 312): ubifs_decompress: cannot decompress 2769 bytes, compressor lzo, error -22

UBIFS error (pid 312): read_block: bad data node (block 151, inode 2528)

UBIFS error (pid 312): do_readpage: cannot read page 151 of inode 2528, error -22

UBIFS error (pid 312): ubifs_decompress: cannot decompress 2769 bytes, compressor lzo, error -22

UBIFS error (pid 312): read_block: bad data node (block 151, inode 2528)

UBIFS error (pid 312): do_readpage: cannot read page 151 of inode 2528, error -22

 

Below is step we are using to flash filesystem

./ubiformat -s 2048 /dev/mtd4

./ubiattach /dev/ubi_ctrl -m 4 -O 2048

/ubimkvol /dev/ubi0 -N rootfs_B_volume -s 480MiB

 mkdir /mnt/ubifs

cp /home/filesys/* /mnt/ubifs/ -rf

umount /mnt/ubifs

./ubidetach /dev/ubi_ctrl -m 4

Below is bootargs:

setenv bootargs 'console=ttyO0,115200n8 ip=dhcp ubi.mtd=4,2048 root=ubi0:rootfs_B_volume rootfstype=ubifs earlyprintk mem=128M, notifyk.vpssm3_sva=0xBF900000'

Does any one has faced  such error because we have stuck here. Without solving this error we can't  release our product in market.

Regards,

Jemish

  • Hi

    I am not sure if this is the case, but your problem may be caused by wrong ECC algorithm in lower level MTD driver. If you are using NAND device, you have to choose correct ECC (at least BCH4). SDK kernel had some issues with BCH4 implementations. Check it and make sure your settings are applied both in bootloader and kernel and are really supported by the code.

    Greg

  • Hi Greg,

    Thanks for you quick reply. We are using BCH8 ECC algorithm at boot loader  and kernel level. Do you have any direction for us? Or any suggestion for us?

    Regards,

    Jemish

  • You can check with your NAND device what kind of algorithm is required. I know there were some topics on forum that SDK kernel does not support BCHx, but only Hamming Code. I saw several commits related to bugfixes in git. You may want to check git repo.

    Did you try jffs2? How do you flash your filesystem?

  • Hi Grzegorz,

    Sorry for the late reply, stuck somewhere else. I referred link sent by you. There are lot's of bug fixes available there . Can you direct me which one fix is closely related to our problem. So that I can debug further.

    Regards,

    Jemish

  • Hi All,

    Is anyone has any update on this because this issue becomes shows stopper for us before putting demo  version of product in market.

    Regards,

    Jemish

  • Hi All,

    Is there any update for this issue? We get stuck here...!

    Regards,

    Jemish

  • Hi All,

    Can I get some help here from any of the community member for this issue?

    Regards,

    Jemish

  • Hi Jemish,

    Sorry for late response. You have to follow changes in nand-omap2 in compare to your particular kernel. I noticed at least below patches since last year. Most of them are related to BCH8 ECC scheme you are using.

    I hope it will help.

    Regards,

    Greg

    http://arago-project.org/git/projects/?p=linux-omap3.git;a=commit;h=1f956dad2be937c0b0e473f4df3860f22129fea9

    http://arago-project.org/git/projects/?p=linux-omap3.git;a=commit;h=8b7c1cf65c436f487dc27600d9ce85dcf013d5fa

    http://arago-project.org/git/projects/?p=linux-omap3.git;a=commit;h=ab3a473b1d5f450655fd0e5bf91daa0ccb161a2f

    http://arago-project.org/git/projects/?p=linux-omap3.git;a=commit;h=3fea6ba96cd5e3d9ab96ece6222b34c2b952851d

    http://arago-project.org/git/projects/?p=linux-omap3.git;a=commit;h=858cee95a26b3544e6f99c7480d6ecc30db038a7

    http://arago-project.org/git/projects/?p=linux-omap3.git;a=commit;h=4c017a745a579d80a0a7af65b57261c62e591a8d

    http://arago-project.org/git/projects/?p=linux-omap3.git;a=commit;h=2ad4f937b40e0a6489fd5c349400c56f6c09769b

  • Hi Patel,

    Is your issue resolved? Is Greg's suggestion worked for you?

    For now, we have met the similar issue with you.

    Regards,

    Rocky

  • Hi Rocky,

    I gone through the patches suggested by Greg. I have applied which are most relevant to our requirement. So after applying this patches we don't encounter any error as we were facing. I have also attached patch for your reference.

    Regards,

    Jemish

    diff -Naur linux-2.6.37-psp04.04.00.01/drivers/mtd/nand/omap2.c linux-2.6.37-psp04.04.00.01_new//drivers/mtd/nand/omap2.c
    --- linux-2.6.37-psp04.04.00.01/drivers/mtd/nand/omap2.c	2013-09-28 19:40:38.961108874 +0530
    +++ linux-2.6.37-psp04.04.00.01_new//drivers/mtd/nand/omap2.c	2013-09-28 17:16:33.404925102 +0530
    @@ -839,10 +839,25 @@
     
     		/* read respective ecc from oob area */
     		chip->cmdfunc(mtd, NAND_CMD_RNDOUT, oob_pos, page);
    +#if 0
     		if (info->ecc_opt == OMAP_ECC_BCH8_CODE_HW)
     			chip->read_buf(mtd, oob, 13);
     		else
     			chip->read_buf(mtd, oob, eccbytes);
    +#endif
    +//To fix ubifs errors
    +/*
    +ti81xx: nand: fix 8-bit bch ecc scheme while reading a page
    +GPMC requires 13 bytes of ECC for every 512 bytes to implement
    +8-bit BCH scheme in the hardware. But ROM code uses 14 bytes of
    +ECC for every 512 bytes. So, to align our Uboot and Kernel with
    +the ROM code (so that the ECC layout is common throughout),
    +we implement 14 bytes of ECC for every 512 bytes of data and set
    +the 14th byte to 0 (since the GPMC requires only 13 bytes).
    +This patch accounts for considering 14 bytes of ECC for every
    +512 bytes of data (instead of 13 bytes), while reading a page.
    +*/
    +                chip->read_buf(mtd, oob, eccbytes);
     		/* read syndrome */
     		chip->ecc.calculate(mtd, p, &ecc_calc[i]);
     
    @@ -858,8 +873,8 @@
     
     	for (i = 0 ; eccsteps; eccsteps--, i += eccbytes, p += eccsize) {
     		int stat;
    -
    -		if (!(chip->ops.len & 0x7ff)) {
    +/*   Remove hard coding of 2k page size and make it generic */
    +//		if (!(chip->ops.len & 0x7ff)) {
     			stat = chip->ecc.correct(mtd, p, &ecc_code[i],
     					&ecc_calc[i]);
     
    @@ -867,7 +882,7 @@
     				mtd->ecc_stats.failed++;
     			else
     				mtd->ecc_stats.corrected += stat;
    -		}
    +//		}
     	}
     	return 0;
     }
    @@ -985,9 +1000,21 @@
     
     				bit_pos   = err_loc[j] % 8;
     				byte_pos  = (BCH8_ECC_MAX - err_loc[j] - 1) / 8;
    -				if (err_loc[j] < BCH8_ECC_MAX)
    -					dat[byte_pos] ^=
    -							1 << bit_pos;
    +//				if (err_loc[j] < BCH8_ECC_MAX)
    +//					dat[byte_pos] ^=
    +//							1 << bit_pos;
    +                                if (err_loc[j] < BCH8_ECC_MAX) {
    +                                        /*
    +                                         * Check bit flip error reported in data
    +                                         * area, if yes correct bit flip, else
    +                                         * bit flip in OOB area.
    +                                         */
    +                                        if (byte_pos < 512)
    +                                                dat[byte_pos] ^= 1 << bit_pos;
    +                                        else
    +                                                read_ecc[byte_pos - 512] ^=
    +                                                        1 << bit_pos;
    +                                }
     				/* else, not interested to correct ecc */
     			}
     
    diff -Naur linux-2.6.37-psp04.04.00.01/fs/ubifs/sb.c linux-2.6.37-psp04.04.00.01_new//fs/ubifs/sb.c
    --- linux-2.6.37-psp04.04.00.01/fs/ubifs/sb.c	2013-09-28 19:38:58.889106747 +0530
    +++ linux-2.6.37-psp04.04.00.01_new//fs/ubifs/sb.c	2013-09-28 17:07:41.488913796 +0530
    @@ -714,9 +714,15 @@
     			goto out;
     		lnum = ubifs_next_log_lnum(c, lnum);
     	}
    -
    +// fix a bug in empty space fixup
     	/* Fixup the current log head */
    -	err = fixup_leb(c, c->lhead_lnum, c->lhead_offs);
    +//	err = fixup_leb(c, c->lhead_lnum, c->lhead_offs);
    +       /*
    +        * Fixup the log head which contains the only a CS node at the
    +        * beginning.
    +        */
    +       err = fixup_leb(c, c->lhead_lnum,
    +                       ALIGN(UBIFS_CS_NODE_SZ, c->min_io_size));
     	if (err)
     		goto out;
     
    
    

  • Hi Greg,

    Thanks for you help and suggestion it really help us to solve our issue.

    Regards,

    Jemish

  • I am glad I could help you.

    Greg

  • Jemish, Greg,

    Thank you !!

    Regards,

    Rocky

  • Hi Jemish,

    I verified your patch 6433.ubifs__error_fix.txt, and it worked for me! Your patch really help me a lot and saved lots of my efforts.

    Very much thanks again!!

    Regards,

    Rocky