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

RBL is accessing wrong block address in search for UBL descriptor

Wandson Borges
Prodigy 50 points

I'm working on a project based on DaVinci TMSDM355ZCE 270 ($4A-97AC84W EI).
I can succesfully boot a user boot loader from UART and from SD-CARD.
When I boot UBL and U-boot from these interfaces, we can succesfully acess the NAND (MT29F2G08AADWP:D) flash interfacing the AEMIF. I can write and read pages.
However, I cannot boot from this same NAND Flash. Through an oscilloscope, I verify that as soon as the DM355 is powered on, the RBL  perfoms the following steps, as expected:
-it resets flash;
-it reads the id correctly: 0x2CDA8095 ;
-it reads a sequence of 24 blocks in an attempts to find the correct descriptor;
-it boots from sdcard as it can't find descriptor.
The problem is that the RBL is expected to read blocks from 1 through 24 in its search for the descriptors,
but the oscilloscope shows us that it is actually reading blocks from 25 through 49.
The first read page address is 0x000640 (That is 0x320000 in the ARM address space).
What would make the RBL try to access page 0x000640?


I also copied the entire block 1(descriptor and ubl)  into the block 25, which the RBL is trying to acccess first (0x000640).
The correct descriptor was read from block 25 but still the ubl was not load.
I also observed that before the RBL issues the reset command, it issues four read cycles and then four write cycles without asserting ALE neither CLE high.
This flash boots from the development kit EVMDM355.

 

Appreciate any help.

Regards,

Wandson

  • 0
    TI__Expert 6850 points

    Wandson,

    If the RBL is reading block 25 to 49, it suggests that the NAND boot is configured for "FAST BOOT", which is not supported in DM355.

    Please see Section 11.2.1.3 in http://focus.ti.com/lit/ug/sprufb3/sprufb3.pdf for more details.

    Please make sure that the external pin, DEEPSLEEPZ/GIO0, is NOT driven low during chip reset (which will select fast NAND boot mode).

    In response to the second question, ARM address space is not following the NAND page size (here 2048 bytes). 0x000640 is an absolute address in ARM address space (could be start address of the code/jump address etc... in ARM RAM). Can you please provide more information regarding 0x000640 (where/how it is used)?

  • 0 in reply to Jeff Hayes
    Prodigy 50 points

    Jeff,

    Thanks for the help.

    I only got to know your reply recently (for some reason I didn't receive a notification email), but I am answering anyway, despite the long time, to make clear the solution of this problem, and to give thanks.

    The GIO00 pin was indeed being driven high. That time I found out through an errata.

    Regards,

    Wandson