• State Resolved
  • Locked Locked
  • Replies 5 replies
  • Answers 1 answer
  • Subscribers 98 subscribers
  • Views 5975 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

Badblock management way or tools?

Ankur Tank
Expert 2985 points

Is there any way/tool/utility to correct the badblock on the NAND device ?

We are having custom board based on beaglebone but instead of mmc we have NAND flash. MTD partitions on the NAND are as follows,

mtd0:MLO
mtd1:MLO
mtd2:MLO
mtd3:MLO
mtd4:u-boot
mtd5:u-boot backup
mtd6:kernel
mtd7:kernel Backup
mtd8:RFS

RFS has two UBI volumes rootfs & rootfs2 and at a time one is used for booting the board.

Now as NAND flash is used there can be a badblock on the NAND chip or may develop badblock over a time. UBIFS handles the bad block by reserving the space for badblock. UBI maps badblock to the reserved block. So there is badblock handling there.

But what about other partitions, what if there are bad blocks on those partitions ?
is there any way to detect and correct badblocks on the those partitions,
1. Primarily without loosing data OR
2. With losing data

I searched on net and found that for ext filesystems there is a utility called "badblocks" but is there a version for flash memory ?
Is there any other way to correct badblock on the the device.

I understand that mtd drivers also has some badblock management, they skip the badblocks while writing and reading but is that enough ?

I also know that NAND chip manufacturer also guarantees that chip wont have more than X number of badblocks.

Seeing all this, is it required to worry about badblocks while designing system ? Is it required to handle it from userspace ? If not on active partition, is it required to be done on backup partitions ?

Any suggestions/pointers appreciated,

Thanks in advance.

  • 0
    TI__Guru** 116100 points

    Hi Ankur,

    But what about other partitions, what if there are bad blocks on those partitions ?
    is there any way to detect and correct badblocks on the those partitions,

    The software code written in MLO, u-boot and linux kernel for the ECC error detection & correction mechanism by default.

    I understand that mtd drivers also has some badblock management, they skip the badblocks while writing and reading but is that enough ?

    You have to erase the NAND flash partition before flashing/writing into NAND to avoid bad blocks in image area(data: /dev/mtdX )  because block gets skipped when there is non 0xFF value found while erasing.

    You dont worry about ECC mechansm in MLO, U-boot, Linux kernel and Its well handled by TI, but you need to select which type of ECC is required.

    1.1 bit ECC (Hamming)

    2.4 bit ECC (RS, BCH)

    It is depends on which type of NAND has been used (ie SLC, MLC)

    And also, You can make it as read only partition in linux kernel forMLO and u-boot sections.

    mtd0:MLO
    mtd1:MLO
    mtd2:MLO
    mtd3:MLO
    mtd4:u-boot
    mtd5:u-boot backup
    mtd6:kernel
    mtd7:kernel Backup
    mtd8:RFS


    Why do you have so many MLO copies in multiple partitions?

    Is there any intended reasons exists?

    Please refer TI wiki to know more about ECC

    http://processors.wiki.ti.com/index.php/NAND_ECC_Generation_for_DaVinci_Family_of_Devices

    http://processors.wiki.ti.com/index.php/Checking_ECC_operation

    http://processors.wiki.ti.com/index.php/Error_Correction_User_Guide

  • 0 in reply to Titusrathinaraj Stalin
    Expert 2985 points

    Hi Titus,

    Thank you for reply,



    You have to erase the NAND flash partition before flashing/writing into NAND to avoid bad blocks in image area(data: /dev/mtdX )  because block gets skipped when there is non 0xFF value found while erasing.



    We are erasing atleast before flashing SPL, u-boot and Kernel.
    And for rootfs(UBIFS),i suppose, ubi/mtd layer must be handling it.


    Why do you have so many MLO copies in multiple partitions?


    I think its just for backup, and as far as i know ROM code also tries to boot them one by one in a sequence, if one MLO copy fails to boot.



    It is depends on which type of NAND has been used (ie SLC, MLC)

    And also, You can make it as read only partition in linux kernel forMLO and u-boot sections


    We are having SLC NAND from micron, with part number MT29F2G08ABAEAH4(256MB). We are using 4 bit HW ECC algorithm.
    Evenif when we make MLO, u-boot, uImage and dtb partition read only there is possibility of having bad blocks right ?

    1. What if one day in working partition let's say mtd6(uImage) working partition gets 2 bit flips which ECC algorithm will correct, and consider that those memory cells are corrupted and remains inaccessible. And second day there are 3 more bit flips occur and it would make uImage stored in flash memory corrupted and non bootable ?

    if possible, how does such situtation be avoided ?

    basically what i am looking at is ,
    1. is there a preventive measure for handling bad blocks ? Apart from driver handling it.
    2. Is there a corrective measure for handling bad blocks ?

    Thanks in advance!

  • 0 in reply to Ankur Tank
    TI__Guru** 116100 points

    Hi Ankur,

    I will try to answer your questions.

    You have to understand, What is badblock and what is bitflips? (I think that you may aware; may be you have done lot of research on this)

    As per my understanding,

    When one NAND block is losing its reliability (ie holding data) then that block has been called badblock.

    Two types of badblocks

    1) The first type consists of manufacturing defects caused by either design/microcode defects or process issues, such as impurities in the air or chemicals used to manufacture the wafers.
    2) The second type of defect is wear related (usage) 

    In case bitflips,

    NAND flash is prone to bit flips;


    1) While reading/writing at cell; It will affect near cells.

    2) Stress at cells more reading /writing.

    3) Due to Power failure.

    ECC mechanism has been used to correct bit flips and not correct the badblcoks.

    We are erasing atleast before flashing SPL, u-boot and Kernel.
    And for rootfs(UBIFS),i suppose, ubi/mtd layer must be handling it.

    UBI layer will handle wear level mechanism by using LBA (logical block addressing)

    I think its just for backup, and as far as i know ROM code also tries to boot them one by one in a sequence, if one MLO copy fails to boot.

    I think that these many partitions are not required instead you can create one MLO partition and write multiple copies on it continuously.

    then, You have to mention no of blocks to write MLO copies        RBL


    1. What if one day in working partition let's say mtd6(uImage) working partition gets 2 bit flips which ECC algorithm will correct, and consider that those memory cells are corrupted and remains inaccessible. And second day there are 3 more bit flips occur and it would make uImage stored in flash memory corrupted and non bootable ?

    RBL --> UBL (MLO) --> U-BOOT --->  KERNEL --> FILESYSTEMS

    All the sections has their own ECC support.

    If any bitfips occurs in UBL then RBL(support 1 bit ecc) will try correct those bitflips (before going to put into RAM) and If any bitflips occurs in U-BOOT section then UBL will try to correct those bitflips and vice versa.

    Coming to your assumptions,

    If any bitflips occurs in kernel area the u-boot (you have to say which type of ECC ; ie 1bit or 4 bit or BCH)  will correct those bitflips and then copy the uImage into RAM.

    1. is there a preventive measure for handling bad blocks ? Apart from driver handling it.

    Some of the NAND devices support on-die ECC which NAND flash will take care of bitflips errors (you need to disable ECC support in all the sections)

  • 0 in reply to Titusrathinaraj Stalin
    Expert 2985 points

    Just to close this question and hope that someone having similar task gets some help, I putting below content here,

    Bad Block

    Bad Blocks are blocks that contain one or more invalid bits whose reliability is not guaranteed. Bad Blocks may be present when the device is shipped, or may develop during the lifetime of the device

    Or

    Block in which number of bit flips are more than the what error correction code can handle.

     Initial Bad Blocks:

    Due to production yield constraints and the pressure to keep costs low, NAND flash devices ship from the factory with a number of bad blocks. NAND flash manufacturers specify that up to 2% of the SLC flash can contain bad blocks; the number for MLC flash is about 5%;

    Accumulated Bad Blocks:

    Due to multiple write/erase cycles, trapped electrons in the dielectric cause a permanent shift in the voltage levels of the cells. When the voltage level shifts enough, this will be observed as a read, write, or erase failure.

    Error source and type

     The source of error could be over-programming, program disturb, charge loss, charge leakage between neighboring cells or charge trap in floating gate oxide.

     Not all of them are unrecoverable; therefore they have been divided into two groups

    1. Soft ECC errors. (Temporary ECC errors)
    2. Hard ECC errors. (Permanent ECC errors)

     Hard errors are the ones that are non- recoverable; the charge trap belongs to them. The charge trap is responsible for wear-out of the memory cells over time and it appears at erase or program operation.

    The other group, the soft errors can be fixed by block erase/reprogram cycle. They usually appear at read operation and could be invisible to the user as the ECC can correct them.

     

    The memory use scheme influences the bit error rate. Partial-page programming, non-sequential pages programming within the block, excessive read per block without erase as well as non-equal number of read operation within a single block increase number of the read disturb errors.

     Soft ECC errors are recoverable and Hard ECC errors are not recoverable, and may make block a bad block.

    Sr.

    Condition when Bad block occur

    Possible solution

    1.

    Over programming

    Wear leveling

    2.

    Program disturb

    Erase and program again

    3.

    Charge loss

    Erase and program again

    4.

    Charge leakage between neighboring cell

    Erase and program again

    5.

    Charge trap in floating gate oxide.

    NONE (BAD BLOCK).

     There is no user space tool available to remove the bad blocks in the NAND. There are some precautions one can take while using NAND and These precautions one MUST keep in mind while designing Linux based embedded system.

    1. Use flash file system with wear leveling.
    2. Erase NAND partition before writing to it.
    3. Partition size should be in multiples of erase block size and more than erase block size specially for small partitions,

    If device tree blob can be accommodated in single block make device tree partition equal to 2 erase block wide.

    Consider a case Erase block size is 128K, you might keep dtb partition size equal to 1 erase block and if there is a bad block in the dtb partition, it will be inaccessible and you might have to re-partition NAND in that case.

    Bad blocks can be removed manually by scrubbing NAND but it is not safe to do that and it should not be done in general because NAND scrub removes the factory marked bad blocks also.

    Refer below link for more detail (I haven’t tried it)

    http://www.stlinux.com/howto/NAND/clean

    If NAND is purchased from good manufacturer then it lasts more than its erase/write life spans.

    I had run NAND torture test more than 800,000 on the NAND partition and still I didn’t observe the bad block, typical life span mentioned in datasheet is 100,000 erase/write cycles. While this does not guarantee anything but it gives some level of confidence that bad block occurrence won’t be so obvious in normal operation of the system.

    Note: NAND tests are available in the Linux kernel and it can be compiled as module

    A very good article on NAND flash is available at below link, It will help one understand about NAND.

    http://www.design-reuse.com/articles/24503/nand-flash-memory-embedded-systems.html

  • 0 in reply to Ankur Tank
    TI__Guru** 116100 points

    Hi,

    Superb,

    Thanks for your update.