• State
  • Locked Locked
  • Replies 6 replies
  • Subscribers 99 subscribers
  • Views 585 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.

OMAP-L13x - Are there new boot code size restriction in d800k008 compared to d800k006?

AnBer
Mastermind 30150 points

Team,

Could you please help with the following?

We’ve encountered an issue with using our single stage boot process with the d800k008 boot ROM, that doesn’t seem to be a problem with the d800k006 and just wanted to get confirmation that this was indeed the case.

In migrating to using d800k008 we’ve found that the Boot ROM only appears to process the first 10 pages from flash (20K) of our AIS script.  With d800k006 on a near identical development board (for boot purposes they are identical) the complete AIS script (it’s a rather large 380k including all our debug and test code) gets loaded.  I’ve also tested this on some other boards to confirm that the version of the boot ROM is the common factor and also confirmed that the AIS script is loaded into flash and error free on the boards that exhibit this problem.

This new restriction doesn’t appear to be mentioned in the release notes or the errata, so I wanted to check whether:
a)      You could confirm that this new restriction is intentional?
b)      If not, whether there are any work-arounds (short of going to a two stage boot process)?
c)       And if there will be any plans to provide an update to the silicon to fix it?  And if so, what kind of timescale would we be looking at?

Thanks in advance,

Anthony

  • 0
    TI__Mastermind 30150 points

    Some additionnal information:

    The flash we’re using is a 128M NAND flash with 128K Blocks and 2k Pages (ONFI compliant).  The same flash is being used on all boards.

    While I tested a couple of different boards, there were two that were exactly the same hardware revision with the only difference being the silicon version of the OMAP – the one with the 2.1 silicon stopped loading the AIS script after reading the first 10 pages from flash while the one with the 2.0 silicon loaded the complete AIS script. 

    In addition, I am able to load our boot code using a debugger (on all boards) and access to NAND and DDR is okay in all cases – our debug code allows me to successfully read the AIS script from all boards to confirm that it has been correctly programmed.

  • 0 in reply to AnBer
    TI__Mastermind 35645 points

    Hi AnBer,

    Thanks for your post.

    You shall check for the ROM revision history in Appendix E of Application report (SPRAB41D–August 2011) as below:

    http://www.ti.com/lit/an/sprab41d/sprab41d.pdf

    In the above doc., E.4 provides the details on ROMID: D800K008, Silicon Revision 2.1

    Also, please refer Appendix B for the details of supported NAND device (like, pages per block, size etc.)

    Thanks & regards,

    Sivaraj K

    ------------------------------------------------------------------------------------------------------- 
    Please click the Verify Answer button on this post if it answers your question.
    --------------------------------------------------------------------------------------------------------

  • 0 in reply to Sivaraj Kuppuraj
    TI__Mastermind 30150 points

    HI Sivaraj,

    Thanks for the comments.

    From the doc you pointed (in appendix E) I have seen that some substantial changes occurred for NAND boot on rev 2.1.
    I have not check the exact NAND config (page, block, ..etc) but since it was fully booting on rev 2.0 I thought that it would do as well on rev 2.0.

    Enclosed are the dumped from the internal registers done with a Lauterbach emulator (this is equivalent to what the OMAP-L1x Debug GEL file will read on CCS).

    Anthony

    AISLoadFailure.zip
  • 0 in reply to AnBer
    Prodigy 20 points

    Hi Anthony, Sivaraj,

    Just to confirm, our NAND device is in the list of supported devices (128MB size, 2048 + 64 bytes per page, 64 pages per block) and our AIS script works okay with the version 2.0 silicon, but fails with the version 2.1 silicon.

    I've been doing some more testing and it would appear that the problem is not that the Boot ROM only processes a set number of Flash blocks, as removing or resizing (with CRCs disabled) load commands\blocks causes the Boot ROM to stop processing the AIS script earlier

    In case it's of help, I've extracted a summary of the contents of our AIS script (below) - the load to 0x11800000 (DSP L2 RAM) is loading all '0's and is where the boot ROM stops processing the AIS script after loading 0x4b74 of the 0x4c00 bytes.

    Best regards,

    Steve

     

    Magic: 41504954

    Execute [index=0 / argcount=2]

        PLL0 Configuration

        PLL0CFG0 :001a0001

        CLKMODE :00

        PLLM :1a

        PREDIV :00

        POSTDIV :01

        PLL0CFG1 :00000200

        PLLDIV1 :00

        PLLDIV3 :02

        PLLDIV7 :00

    Execute [index=5 / argcount=5]

        EMIFA ASYNC Configuration

        CE2CFG :00

        CE3CFG :242181

        CE4CFG :00

        CE5CFG :00

        NANDFCR :02

    Execute [index=3 / argcount=8]

        mDDR/DDR2 Controller Configuration

        PLL1CFG0 :1a010001

        PLLM :1a

        POSTDIV :01

        PLLDIV1 :00

        PLLDIV2 :01

        PLL1CFG0 :00000000

        PLLDIV3 :00

        DRPYC1R :c3

        SDCR :207c622

        SDTIMR1 :12912a08

        SDTIMR2 :380e0e20

        SDRCR :40d

        OTHER :00000000

        RSVD :0099f82e30

        PASR :00

        RSVD :00

        ROWSIZE :00

        CLK2XSRC :00

    CMD_BOOTTABLE

        Set type=2: address=b000001c, data=00000005, sleep=00000000

    CMD_BOOTTABLE

        Set type=2: address=01e2c004, data=00000030, sleep=00000000

    Execute [index=7 / argcount=1]

        Power and Sleep Controller Configuration

        PSCNUM:00000000

        MODULE:0000000f

        PD:00000001

        STATE:00000003

    EnableCRC

    Load: address:1183e800 size:00000020

    Validate CRC: crc=f612677a, seek=ffffffc8

    Load: address:1183e820 size:00000340

    Validate CRC: crc=a9b9f29b, seek=fffffca8

    Load: address:1183eb60 size:00000040

    Validate CRC: crc=10f21e29, seek=ffffffa8

    Jump 1183e800

    Load: address:11800000 size:00004c00

    Validate CRC: crc=b06d006e, seek=ffffb3e8

    Load: address:c1000000 size:00000080

    Validate CRC: crc=f10cec75, seek=ffffff68

    Load: address:c1000080 size:00039e40

    Validate CRC: crc=d8e474bf, seek=fffc61a8

    Load: address:c1039ec8 size:00018f38

    Validate CRC: crc=71f93a42, seek=fffe70b0

    Load: address:c1052e00 size:00000bc0

    Validate CRC: crc=71011a5f, seek=fffff428

    JumpClose c1000000

  • 0 in reply to Steven Aris
    Prodigy 20 points

    Is it possible that D800K008 uses DMA to read\write from\to NAND and D800K006 doesn't?

    While I can't explain why the Boot ROM is only copying a specific amount of code from NAND - and it appears to be reliably consistent - relaxing the timings for the NAND EMIFa interface appears to allow the Boot ROM to copy the complete boot code.  This isn't an issue with the 2.0 silicon.

    While I can't see any mention of DMA in the ROM revision history for the 2.1 silicon, I have noticed that "page data is read from the EMIF as 32-bit words instead of 8-bit bytes".

    Could you please confirm whether or no there has been a change to using DMA between D800K006 and D800K008...and if not, exactly what else has changed that could be effected by changing the NAND EMIFa timings?
  • 0 in reply to Steven Aris
    TI__Mastermind 30150 points

    Steven,

    From what I have seen both D800K008 and D800K006 do use the CPU to read NAND at boot. DMA is not used at all.

    One think that seems to have changed is that the NAND boot seems to support fast boot. Depending on a given boot pin the PLL will be initialized differently by the bootloader. This could exaplin the timings issues as the EMIF timing would be different if PLL settings are different.
    Could you check the boot pins to see if fast boot is used?
    Also check the PLL registers with the debugger while CPU is still executing ROM code to see if there are differences between the D800Kxxx ROM code?

    See appendix E of boot app note - SPRAB41D.

    BR,

    Anthony