• State TI Thinks Resolved
  • Locked Locked
  • Replies 2 replies
  • Answers 1 answer
  • Subscribers 98 subscribers
  • Views 2485 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.

NAND bad block search policy on Kernel and U-Boot

Guilherme Costa
Intellectual 635 points

I was going through the Kernel & U-boot codes, and I've found out that U-Boot only checks for bad block markers in the first two pages of an eraseblock. There is even a flag NAND_BBT_SCANALLPAGES, but it is not the default option (at least on the version I am working with).

Why is there such an option? Isn't it better (and safer) to always search every page in a block?

Regards,

Guilherme

  • 0
    TI__Mastermind 43955 points

    Hi Guilherme,
    In my understanding, generally when the block is not operating properly (not able to keep '0' or '1') then we make it as bad, when we do this, we will mark it in first or second page of erase block.
    If first page doesn't have 0xFF after erase then we make it as bad block.

    Refer to this doc, "Recognizing Bad Blocks"



    Refer to this doc, page no 2

    Refer to this link, "NAND page"

    Refer to this link too, "Bad Block Marker"

  • 0 in reply to Shankari G
    Intellectual 635 points

    Shankari,

    I'm asking this question because I've noticed an odd behaviour regarding bad block marking by U-boot (though I still need to check how the kernel handles this):

    Let's say we have a nand with the following features:

     Memory Size 128 MB

     Sector size 128 KiB

     Page size      2048 b

     OOB size         64 b

     Erase size   131072 b

    If I try and mark a block as bad manually (via nand markbad), the following happens:

    U-Boot@UCC3# nand markbad 0x4290000
    block 0x04290000 successfully marked as bad
    U-Boot@UCC3# nand bad

    Device 0 bad blocks:
      04280000


    Everything seems fine. However, after a reboot, the system loses the information. Sifting through the code, I found the it is only checking the first two pages OOB. Note however that the block that gets marked as bad is block 0x4280000, which is aligned in memory with the eraseblock size (1st page in the eraseblock). Also, if I dump the oob info from 0x428000, is is not flagged as bad, but  in 0x429000, the first byte is still 0x00, indicating it as bad.

    If I mark the 1st or 2nd page in an erase block as bad, then the information persists through boot. Also, I've verified that we are not using a NAND based bbt.


    My main concern is that, because this checking shared between functionalities, everytime we erase a block, we keep losing bad block information, because inner pages (i.e. not the 1st or 2nd in an eraseblock), are flagged as good, which, in my point of view,  is a bad thing.

    So, I have two questions:

    - Why is this the default behaviour? It seems to me a bad idea to check only the first two pages, since any block could go bad.

    - If this is indeed the default behaviour, it seems to me that it is due to performance reasons. So, in this case, should we mark the whole eraseblock as bad (by writing 0x00 to the 1st or 2nd pages) if we find a single bad page? Isn't this also a bad solution, since we will be marking 128kiB as bad due to a single page? Shouldn't this control be made at a smaller level (i.e. page level)?


    By the way, we are using U-Boot 2013.01.01 from SDK6, and our NAND is a MT29F1G08ABBDA,

    Regards,

    Guilherme