• State TI Thinks Resolved
  • Locked Locked
  • Replies 6 replies
  • Answers 1 answer
  • Subscribers 102 subscribers
  • Views 2333 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

[DM814x EVM] Unable to boot from Spansion NAND S34ML02G200TFI000

Thomas Doering
Intellectual 575 points

Hi everyone,

Some weeks ago, we tested Spansion S34ML02G100TFI000 with success using u-boot. We could read, write and boot from that flash. Since that NAND will be EOL later this year we want to switch to the successor S34ML02G200TFI000. And now we have problems booting from that NAND.

Writing (and reading) the u-boot bootloader works as expected. But the board just won't boot from it.

The data sheet mentions two main differences:
S34ML02G100TFI000: "64byte spare area" and "1-bit ECC" (ONFI Parameter Page, Byte 112 => 01h)
S34ML02G200TFI000: "128byte spare area" and "4-bit ECC" (ONFI Parameter Page, Byte 112 => 04h)

So, does anyone have any idea, why the boards RBL won't boot from the new NAND?

Greetings,
Thomas

  • 0
    TI__Guru**** 170625 points
    Hi Thomas,

    128byte spare area needs BCH16, 64byte spare area needs BCH8. There are some e2e discussions regarding 128byte spare area BCH16, see below:

    e2e.ti.com/.../450963
    e2e.ti.com/.../454707
    e2e.ti.com/.../465079

    Regards,
    Pavel
  • 0 in reply to Pavel Botev
    Intellectual 575 points

    Hi Pavel,

    We have another NAND Flash here (Toshiba TC58NVG1S3HTAI0) which also has a "128byte spare area"... and that one works (when writing the bootloader with BCH8)?!

    Greetings,
    Thomas

  • 0
    Prodigy 65 points
    Hi Thomas,

    My name is Bacem Daassi and I'm part of the application engineering team at Cypress (former Spansion).

    You're absolutely correct! These are the main differences between our S34ML-1 and S34ML-2 NAND products.
    Please make sure to enable sufficient ECC correction level in u-boot and Linux to ensure proper support of the S34ML-2.
    We also saw ins some cases that some controllers boot usually with 1-Bit ECC which might be enot enough in some cases for our NAND.

    Please make sure that the S34ML-2 is being properly detected with 128bytes in the spare area after the ONFI table is being read out of the NAND. The best way to do it is to use a debugger or debug printf if you don't have a debugger at hand.
    You can also compare the RAM content into which the u-boot was loaded into from NAND, with the expected u-boot binary that's in NAND.
    Make sure also that there was not uncorrectable ECC errors while reading u-boot.

    I hope this helps. Thanks!

    Best regards,
    Bacem Daassi
    Cypress / Spansion
  • 0 in reply to Bacem Daassi
    Intellectual 575 points
    Hi Bacem,

    Thanks for those insights.

    To clarify my initial post. Once the system is up and running (using a UART-Bootloader) I have no issues accessing the NAND flash. It is the internal DM814x Rom Bootloader (RBL) having issues here. So I have no way of controlling that. Since I have no access to the RBLs code, I can't debug or "printf" it.

    Regards,
    Thomas.
  • 0 in reply to Thomas Doering
    Prodigy 65 points
    Hi Thomas,

    Based on your explanation, my guess here is that RBL is not loading the image properly into RAM and a valid cause for this would be a wrongly configured ECC correction strength.
    Could you try the following:
    - Load the image from NAND into RAM using RBL.
    - Dump the image from RAM using debugger, command line tools, whatever you have available...
    - Compare the dumped image with the expected image that's in NAND.

    This will tell us whether there was any error while loading the u-boot image from NAND into RAM.

    Thanks!

    Best regards,
    Bacem Daassi
    Cypress / Spansion
  • 0 in reply to Thomas Doering
    TI__Guru**** 170625 points

    Thomas Doering said:
    We have another NAND Flash here (Toshiba TC58NVG1S3HTAI0) which also has a "128byte spare area"... and that one works (when writing the bootloader with BCH8)?!

    Thomas,

    Actually the BCH algorithm depends on the page size also. I was thinking your Spansion NAND is of page size 4k+128, but it is 2k+128 which can work fine with both BCH8 and BCH16, below are the pointers for how to calculate this:

    You can check the ROM Code trace vectors to see at which stage exactly the boot flow stuck. For more info see DM814x TRM (chapter ROM Code) and below wiki pages:

    Regards,
    Pavel