Latest kernel from GIT destroys my NAND flash

Hello?

Hello there?

Is anybody home?

Hi,

Is your rootfs in NAND?

If yes, you may need to erase nand (flash_erase) and write your rootfs to nand using the new release.

The problem you were facing is probably caused by mismatching the existing ECC schema with the new ECC schema (bch8) which will cause bad blocks.

Regards,

Yan

Hi,

you seem to miss the point. I reformatted the whole device exactly because you switched to BCH8 ECC. Otherwise I would not even be able to boot, not a single NAND access would have worked, init would not have been executed by the kernel, etc. This is not what is happening. I am losing flash blocks on freshly formatted NAND, even on factory-new NAND (see my original post for this) because the driver reports random ECC errors occasionally for blocks which are perfectly fine.

Here is how you can reproduce the problem:

- Fetch the Texas Instruments' Linux kernel fork 

git clone git://arago-project.org/git/projects/linux-omap3.git

- Switch to the 81xx branch: 

git checkout ti81xx-master

- Now switch to the revision tag I specified:

git checkout 52752d53adda8c345650c5c7000856cffc638208

- Build the kernel

- Flash the kernel to a device

- Reformat the whole device

=> You will see new bad blocks reported for your NAND flash after every boot.

This does not happen e.g.  with (older) revision 3228b1d8e5270ee56002e7f59d839ed8b6b85606.

Thilo,

I have flashed UBIFS on the latest code several times and have never encountered this issue. The UBIFS mount and read/write seem to take place perfectly for me. Can you make sure that the UBIFS image you have created is as per the documentation mentioned here <http://processors.wiki.ti.com/index.php/UBIFS_Support>?

Parth,

did you use the kernel from arago GIT with revision 52752d53adda8c345650c5c7000856cffc638208 like I specified?

I don't use a pre-generated UBIFS image. We use a read-only squashfs with transparent writeable AUFS overlays which store data on a UBI/UBIFS back-end partition. See https://github.com/DFE/HidaV/wiki/File-system-layout for documentation.

Our UBIFS is completely empty initially. It fills up when modifying something on the root fs (overlay) since AUFS only tracks changes to the underlying file system. Even attaching and mounting a completely empty UBIFS will report bad blocks.

I can reproduce the problem even without UBI/UBIFS just by accessing the NAND flash (using e.g. "dd"). I get bad blocks reported even when the NAND is freshly formatted.

Additional info: I'm on a DM8148 EVM dev board.

Thilo,

Have you solved this problem?  I'm encountering the same issue on a DM8168 board.

Thanks,

Jason

No, we were unable to solve the issue, and Texas Instruments is ignoring this (as they, in our experience, seem to ignore the ti81xx platform and its massive Linux problems  as a whole).

We're still using the old kernel release tag "v2.6.37_TI814XPSP_04.01.00.06.patch2". This tag corresponds to commit "745a06cb913ad7a9ab44855aa36d8c012cd5793b" which is referenced in Texas Instrument's original kernel build recipe in their official "meta-ti" OpenEmbedded board support layer. Arago, Yocto, Poky and others use this version to build their firmware.  No-one seems to use more recent versions than that. I think the current GIT head of TI's kernel fork is completely broken and nobody noticed because nobody uses it.

Thilo,

I think the NAND flash on the 8148 EVM is an SLC part.  1-bit HW ECC is sufficient for this.  I was able to change the ECC mode in the latest TI GIT kernel by modifying the following files:

- kernel/arch/arm/mach-omap2/board-flash.c

(board_nand_init function - "board_nand_data.ecc_opt = OMAP_ECC_HAMMING_CODE_HW;")

-kernel/drivers/mtd/nand/omap2.c

(probe function - "pdata->ecc_opt = OMAP_ECC_HAMMING_CODE_HW;")

This change eliminated the problem.

I'm not a NAND expert by any means, but I'm not sure if using BCH8 HW ECC with an SLC part is actually a valid thing to do.  I suspect that the 8-bit ECC is using too much of the OOB space and that UBIFS tries to access some of this space and thus corrupts the ECC.  This might be fixed by modifying the OOB layout, but I did not go down that road.

Jason,

thanks for your reply and also thanks for the workaround you proposed.

We're using Hamming ECC on our systems except for the NAND area we write the bootloader to. Considering your concerns BCH8 would be a valid algorithm to use in NAND, though. I think it's reasonable to use it by default as the current TI kernel code does. Well, it _would_ be reasonable if the driver was not buggy. In fact you are required to use BCH8 ECC if you want to boot from NAND since the ROM loader can only run NAND bootloaders which have been written in BCH8 ECC mode.

We do boot from NAND so your workaround would unfortunately only solve a part of our problem. Also the NAND driver has a buggy sub-page support which breaks UBI and YAFFS2 for some people.

Thilo,

I have almost solved the issue with BCH8. Could you please mail me @ renjith.thomas@pathpartnertech.com