• State Resolved
  • Locked Locked
  • Replies 4 replies
  • Subscribers 101 subscribers
  • Views 831 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.

K2H NAND Boot

Tim Cooper1
Intellectual 980 points

We have a board based on K2H eval board, but with no SPI or I2C flash.  The board does have a 4Gbit NAND flash - same part# as used on eval board.

We are unable to get the board to boot from NAND flash. The board either locks up with no ability to interrogate by emulator, or it ends up in the "no-boot" loop within the boot loader.

We have confirmed, by downloading utilities into RAM under CCS, that we can identify/read/write NAND flash. However, we are unable to boot from NAND flash.  DEVSTAT looks correct; though most of the time we configure the board for no-boot, and then intervene with the emulator and change DEVSTAT to boot from flash.


We have burned a uboot GPH image into NAND flash, starting with the first page.  The burn verifies for its entire length.  We know the image works because we can take the non-GPH image, load it into memory at 0x0c00_1000, and run from there with the emulator.

Questions:

It appears the ROM boot loader must examine the flash contents before copying the image to RAM and jumping to the image.  The first 8 bytes of the GPH image appear to contain a byte count and starting address.  Can someone provide details:  what validation does the boot loader performs on the image? 

If the first two words are size, load address, what endian-ness should these values be?

Also, are there status codes or error conditions within the boot rom that give insight into what has happened?   We note that there is a table containing branches to self (infinite loops) that appear to be error traps for various conditions.

  • 0
    TI__Guru** 116100 points
    Dear Tim,
    How did you flash the u-boot into NAND flash ?
    Have you tried to load the u-boot into MSMC RAM through CCS or UART boot ?
    If you did so, able to detect the NAND in u-boot ?
    Have you modified the NAND code in u-boot if you used different NAND part than EVM ?
  • 0 in reply to Titusrathinaraj Stalin
    Intellectual 980 points
    Hello Titus,

    Thank you for the quick response. Here is some additional information:

    Re: how flashing was accomplished, and how we loaded it:

    We used two different methods:
    1) There is a DSP example project for writing to flash. We built this under CCS, and loaded the image into one of the DSPs, and ran it under emulator control. We loaded the uboot image to be burned into MCMS RAM. The DSP example correctly identified the flash part, erased, programmed and verified the image. We did this with both the gph and non-gph u-boot images. This did not yield a bootable result, though.

    2) The second method was to load the u-boot image into MSMC RAM under emulator control, and run it. Starting address of 0x0c00_1000. This ran U-boot correctly. We then deposited (using emulator load command) a copy of the image to burn at 0x8700_0000 in DDR3. Then, using u-boot commands, we erased the bootloader partition, and reprogrammed it using starting address of 0x8700_0000 and length of 0x5_0000 (we verified the length is the image size rounded to the next block boundary). u-boot reported successful programming of the device. Again this did not result in a bootable NAND flash.

    Regarding detecting NAND: yes, the correct part and geometry has always been detected and reported. This is the 4Gbit flash.

    There are vague references to a bug regarding NAND flash in some of the documentation; can you point me to a reference regarding the issue?

    Also, we have our board configured for no-boot; we set up emulator for halt on reset, and change DEVSTAT[0x0262_0020] to 0x106e7 before continuing execution; our understanding is this will cause the boot code to attempt to boot from NAND flash. (This is a production board based on the EVM design; boot configuration is driven by a CPLD and we are intercepting/forcing the mode in order to bypass the boot configuration generated by the CPLD).

    Regards,

    Tim
  • 0 in reply to Tim Cooper1
    TI__Guru** 116100 points
    Sorry for the delayed response on this.
    Able to boot from NANS flash ?
    I think, the problem is due to boot mode selection, may be, boot mode is not set correctly.
  • 0 in reply to Titusrathinaraj Stalin
    Intellectual 980 points

    Thanks.  The problem was boot from NAND flash.  The root cause was traced to a CPLD that generates the boot configuration signals.  This was incorrect in some cases.  That problem was further traced to some conflicts within the TI document regarding which pins are used for boot configuration.