• State
  • Locked Locked
  • Replies 4 replies
  • Subscribers 97 subscribers
  • Views 324 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 Driver issue in DM355

Thalib
Intellectual 580 points

Hi all,

I have ported the linux to our custom board which is having 64M nand flash, I am geeting following error when mount ting the nand block

 

# mount -t jffs2 /dev/mtdblock2 /mnt/nand/
jffs2: Flash size not aligned to erasesize, reducing to 60896KiB
jffs2: Erase block size too small (16KiB). Using virtual blocks size (32KiB) instead
ECC_STATE_TOO_MANY_ERRS
numErrors=1
mtd->read(0x400 bytes from 0x0) returned ECC error
numErrors=1
numErrors=1
numErrors=1
numErrors=1

 

I found this in some forums that it is due to oob issue. can some one help me how to configure the oob.

Thanks

Thalib

  • 0
    TI__Expert 6385 points

    Hi Thalib,

    Are you using LSP 2.10? If yes, the 4-bit ECC placement in OOB area is dictated by the functions davinci_{read|write}_page_syndrome() in drivers/mtd/nand/davinci-nand.c file. Changing the layout will involve updating these functions.

    Does your NAND device really need 4-bit ECC? In case it can do with 1-bit ECC, then shifting to 1-bit ECC would be another option. This can be done by passing ecc_mode=NAND_ECC_HW in the NAND platform data defined in the DM355 board file.

    I-bit ECC only needs 3 bytes ECC per 512 byte data as against 10 bytes required by 4-bit ECC. This way a lot to OOB area is available for usage by filesystems.

    When you shift between ECC modes, please ensure that you pre-erase the NAND area where you are changing the ECC mode.

    You can observe how the OOB are is being used by dumping the NAND using nanddump command.

    Thanks,

    Sekhar

  • 0 in reply to Sekhar Nori
    Intellectual 580 points

    Hi Sekhar,

    My kernel version is 2.6.10,

    I tried setting it to 1bit ecc, soft ecc, no ecc but it failed and printed all the blocks in the nand as bad block as shown below.

     

    Bad eraseblock 3568 at 0x037c0000

    Bad eraseblock 3569 at 0x037c4000

    Bad eraseblock 3570 at 0x037c8000

     

    Thanks

    Thalib.

  • 0 in reply to Thalib
    TI__Expert 6385 points

    Hi Thalib,

    Does U-Boot report these blocks as bad too? (nand bad command should give a list of bad blocks).

    A block is recognized as bad based on first two bytes in the OOB area. These two bytes should be 0xFF in a good block.

    If there is data written to these bytes, the block will wrongly be reported as bad.

    You can examine the contents of the block using 'nand dump' command in U-Boot and nanddump command in Linux.

    Thanks,

    Sekhar

  • 0 in reply to Sekhar Nori
    Intellectual 580 points

    Hi Sekar,

    Thanks for your help. I have soved this issue. 

    This was due to Linux driver not able to read the data from nand controller. for every read the low level davinci_driver returned 0x0 , hence the bad_block management code marked it as bad block.

     

    Now I have modified the low level stuff and works fine

    Regards,

    Mohamed Thalib. H