• State
  • Locked Locked
  • Replies 7 replies
  • Subscribers 98 subscribers
  • Views 885 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.

U-boot and BCH16 Support

Terry Neill
Intellectual 600 points

Hi folks,

We are currently switching our hardware to a platform that includes a 512Mb flash device.  This device has a block size of 256Kb with a page size of 4Kb.

From reading the DM8148 technical reference manual, it appears that, the internal boot code automatically switches to BCH16 error correction when it discovers a page size of 4K.

This means that we need to program U-boot min into flash with BCH16.  However, the version of U-boot that we have does not support BCH16.

Are there any updates/patches available that allow U-boot to  be modified to support BCH16?

Is there any way to disable ECC checking by the internal boot code on the DM8148 temporarily?

Are there any other tools that can be used to program the flash device other than U-boot?

Thanks in advance,

Terry

  • 0
    TI__Guru**** 170625 points

    Terry,

    You can flash your NAND chip through CCS flash writer tool:

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

    http://e2e.ti.com/support/dsp/davinci_digital_media_processors/f/716/p/333020/1162305.aspx#1162305

    Regards,
    Pavel

  • 0
    TI__Guru**** 170625 points

    Terry Neill said:
    From reading the DM8148 technical reference manual, it appears that, the internal boot code automatically switches to BCH16 error correction when it discovers a page size of 4K.

    Where exactly in the DM814x TRM you have found this?

    Regards,
    Pavel

  • 0 in reply to Pavel Botev
    Intellectual 600 points

    Hi Pavel,

    On page 1048 of the TRM there is a statement:

    "For device ID codes D3h, C3h, D5h, C5h, D7h, C7h, DEh, CEh when manufacturer code (first ID byte)
    is 98h the cell type information is checked in the 4th byte of ID data. If it is equal to 10b then the ECC
    correction applied is BCH 16b/sector."

    We are using a micron device, but I have noted on these forums that other developers have been experiencing similar issues with micron devices that have a 4k block size.

    Is my assumption correct?

    Regards,

    Terry

  • 0 in reply to Terry Neill
    TI__Guru**** 170625 points

    Terry,

    Terry Neill said:

    We are using a micron device, but I have noted on these forums that other developers have been experiencing similar issues with micron devices that have a 4k block size.

    Is my assumption correct?

    Do you actually mean 4k page size (not 4k block size)? Below is one e2e thread discussing 4k page size:

    http://e2e.ti.com/support/dsp/davinci_digital_media_processors/f/717/t/231420.aspx

    I think the first thing you need to do is to check whether the DM814x device supports your specific NAND chip. See DM814x TRM, section 4.7.3 NAND, Table 4-14. Supported NAND Devices

    Best regards,
    Pavel

  • 0 in reply to Pavel Botev
    TI__Guru**** 170625 points

    The below e2e thread might be also in help:

    http://e2e.ti.com/support/dsp/davinci_digital_media_processors/f/716/t/233142.aspx

    BR
    Pavel

  • 0 in reply to Pavel Botev
    Intellectual 600 points

    Hi Pavel,

    I've done some more experimentation with the NAND flash device from U-boot:

    1. The driver seems to be identifying the device OK - it identifies a 512Mb device, 16 bit, 1.8V with 256k block size which is correct.

    2. The driver miscalculates the OOB size as 128 bytes instead of the 224 that it actually is. As 128<224, I'm not overly concerned about this at the moment, I can see where the calculation is done in the code, so it will be easy to fix if required..

    3. If I program one block (block 0) from the U-boot command line (with nandecc hw 2) and then dump the first page of the block immediately after programming, the first two bytes of the OOB data are 0x00 and 0xFF.

    4. From looking at the driver code, it looks like a block is declared bad if the first two bytes of the OOB data on the first page are not 0xFF and 0xFF.  Therefore, it looks like the block is immediately bad after programming.

    I will experiment further, but any thoughts would be appreciated,

    Regards,

    Terry 

  • 0 in reply to Terry Neill
    TI__Guru**** 170625 points

    Terry,

    We had similar discussion into the below e2e thread:

    http://e2e.ti.com/support/dsp/davinci_digital_media_processors/f/716/t/320415.aspx

    Regards,
    Pavel