• State Resolved
  • Locked Locked
  • Replies 6 replies
  • Answers 1 answer
  • Subscribers 100 subscribers
  • Views 549 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.

66AK2H12: NAND flash boot image size

Tim Cooper1
Intellectual 980 points

Part Number: 66AK2H12

I have a revision 4 K2HEVM. 

It boots correctly from SPI flash, but I would like to boot directly from NAND flash.

uboot runs correctly; I have been using uboot commands to alter NAND flash, and then resetting.  NAND is present and reliable, and all experiments use "nand ecclayout set 1" to ensure the ECC is RBL compatible.

I have tried several different GPH executables, all single stage, and I have noticed the following:

- If the image is "large",  it does not boot. Furthermore, RBL hangs, looping somewhere.  It appears that it has initialized the EMIF interface the RBL does not move anything from NAND into MSMC (all images load into MSMC).  This is based on observing memory contents in the emulator when a boot does not complete.

-As an experiment, I copied the contents of the SPI flash (0x5_0000 bytes) from SPI into SDRAM and then into NAND flash.  This worked.  I note this image appears to have a small, first stage boot loader of length 0x2480. This image presumably then loads u-boot from a higher address in SPI flash.

- Before writing the NAND flash copy of the SPI code, I zeroed out the SDRAM copy of SPI from 0x3000 to 0x5_0000.  I then wrote this to NAND flash.  This boots.  (Presumably the first stage boot loader loads, runs, and completes the boot from SPI flash).

- If I change the first word to 0x00ff_0000, increasing the GPH header length, and re-write NAND flash, (so, GPH header with length 0x0000_ff00), the image boots.

- However, if I change the first word to 0x1000_0001 and rewrite NAND flash (so, GPH header indicating a length of 0x0001_0010), the image does not boot.

It appears that GPH images > 64KB do not boot from NAND flash;  from the emulator it appears that the RBL initializes EMIF and then stops based on observing the length of the image.

Is there, in the RBL, a length restriction on the image size when booting from NAND flash?

Thanks.

  • 0
    TI__Guru**** 161600 points
    Hi,

    I've notified the design team to elaborate.

    Best Regards,
    Yordan
  • 0
    TI__Guru** 116950 points
    Please check Advisory 40 and Advisory 41 that relates to NAND boot and make sure that you are not impacted by those issues. I believe that if you have an image that spans across multiple blocks then you may run into the issue described in Advisory 40. Is the block size on the NAND part hat you are using of the size 64KB.

    Regards,
    Rahul
  • 0 in reply to Rahul Prabhu
    TI__Guru** 116950 points
    There is no physical length restriction on the boot image size on NAND. The boot ROM sets up EMIFA, reads the NAND geometry from ONFI NAND and then proceeds to read the image from the NAND as described on page 29 in the ARM Keystone Bootloader User guide:
    www.ti.com/.../spruhj3.pdf

    Can you confirm that you are erasing the NAND before re-writing the image as described here:
    processors.wiki.ti.com/.../MCSDK_UG_Chapter_Exploring

    I am not an uboot expert but have you checked to see if the length restriction is enforced by uboot. I have looped in the uboot expert to see if he has any inputs on this issue.

    Regards,
    Rahul
  • 0 in reply to Rahul Prabhu
    Intellectual 980 points
    Hello Rahul,

    Yes, erasure was confirmed, as was the proper ECC layout.

    There is no length restriction enforced by uboot.

    Perhaps it would be helpful if you could provide information enabling me to determine how far RBL gets. I see there are several areas mentioned in MSMC memory by RBL. When it fails to load, is there something I can look for in MSMC to determine how far it got, and/or why it stopped?
  • 0 in reply to Tim Cooper1
    TI__Guru 50170 points
    HI, Tim,

    Which Processor SDK release are you based on?

    Using NAND boot, you will need to use the ubinized image to program the NAND. The prebuilt, tisdk-serer-rootfs-image-[platform].ubi image in the release package is too big to fit, but you can ubinize the arago filesystem and it should work. There were several discussions on this topic in the forum. Below are 2 for your reference:

    e2e.ti.com/.../659765
    e2e.ti.com/.../679082

    Rex
  • 0 in reply to Rex Chang
    Intellectual 980 points
    Thanks Rex. The problem is more to do with booting than with burning.

    I believe I have a handle on it. The uboot image I started with has a GPH header (from make u-boot-nand.gph) but no null GPH header on the tail end. The manner in which I loaded and burned it probably left nonzero data in the RAM image before committing to flash. This would have looked like an additional header to the RBL.

    As for the experiments with changing the size in the GPH, I see I entered the length incorrectly when crossing the 64K boundary.

    Regards,

    Tim