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

What's the criteria for a valid boot image?

Eric Thosteson
Prodigy 20 points
Other Parts Discussed in Thread: AM1806

I'm booting an AM1806 from an AIS-signed copy of U-Boot from NAND.  

The bootloader's application report (SPRAB41D) mentions the following change in the latest ROM revision (d800k008):

In the Update to NAND boot modes so that if no valid boot image is found at in current block, next block is tried until image is found (within first 32 blocks).

I placed several AIS-signed U-Boot images in the range of blocks from 1-32.  If I intentionally write some garbage over block 1, it jumps to the next U-Boot image on boot as expected.  If I i erase block 1 from within U-Boot (nand erase 20000 20000), the processor hangs on the next boot and never tries to access the later images.  But, I have empty 'padding' blocks between U-Boot images that are skipped as expected in the first case.  The intent is the have as many redundant copies of U-Boot in those first 32 blocks as possible should a block go bad - but it seems, at least in this case, that it stops trying to find a valid boot image prematurely.  

Two questions: 1) What stops RBL from trying the next block besides not finding a valid boot image, and  2) Which is considered a valid boot image - a valid AIS section, or a valid U-Boot image?

Thanks,

Eric

  • 0
    TI__Guru** 116170 points

    Eric,

     Apart from just erasing the block, could you also need to mark it as bad, for the ROM to skip over to the next block.

    What is the version of the ROM/ silicon you are using? The treatment of NAND block check is different between  D800K008 and D800K006 version of the ROM but in both cases it will skip over to the next block only if the block is marked as bad. If a block is marked as good and there is a page read error the ROM D800K006 will abort while on D800K008 there is additional safety mechanism of moving over the next block if there is a page read error inside a good block.

    If it reads a NAND page and is not able to the AIS image, you will see an error code that indicates invalid keyword when you run the OMAPL debug GEL file.

    Regards,

    Rahul

  • 0 in reply to Rahul Prabhu
    Prodigy 20 points

    Rahul,

    Bad blocks are being skipped without a problem.  Good blocks and empty blocks erased via JTAG are also skipped.  I was able to erase blocks 1-9 and put the AIS-signed U-Boot in block 10 and it boots.  I also tried putting a copy of U-Boot in blocks 1-3 (my U-Boot is 3 blocks long), erasing blocks 4 & 5, and putting another copy in blocks 6-8.  In this scenario, if I mark block 1 as bad, it still boots - I'm guessing now from the copy in block 6.  If this is true, then RBL skipped not only bad block 1, but also the good blocks 2 & 3, and the erased blocks 4 & 5.  It's only when I erase block 1 from the U-Boot command line that it fails to boot.  In both cases, I was able to use U-Boot to verify, using nand dump, that the block contents were as I expected.  But, nand dump shows no discernible difference between the block erased through JTAG vs. the block erased using U-Boot.  I can't make any sense of it, but it seems to be unique to blocks erased from U-Boot.  I'm not sure how the RBL is distinguishing the two.

    My ROM version is d800k008 (verified by checking 0xFFFD0008).

    Thanks for the info on the GEL file - I wasn't aware of it.

    Cheers,

    Eric

  • 0 in reply to Eric Thosteson
    TI__Guru** 116170 points

    Eric,

    What is the error code obtained from the GEL when the boot fails after erasing block1. My speculation on this is that the content in block 2 and block 3 also contains valid AIS commands so when it is not able to boot from block 1 it goes to block 2 and starts executing the AIS commands but since it skipped block 1 the device initialization part of the AIS image got skipped over it is not able to execute commands like loading code section in external memory without initializing external memory.

    I would be interested in knowing the error code that you obtain from the ROM while I dig deeper to see if there is a way to know the block and page from which the boot exited. You might also find this post interesting to gain insight into how the RBL works in case of NAND boot.

    http://e2e.ti.com/support/dsp/omap_applications_processors/f/42/p/133035/479130.aspx#479130

    Could you also provide a dump of the 0xFFFF0700 - 0xFFFF0800 memory locations so thatI can analyze the failing case for you.

    Regards,

    Rahul

  • 0 in reply to Rahul Prabhu
    Prodigy 70 points

    Hi Rahul,

    I've been working with Eric on this issue and have reproduced the issue he describes and captured the information you have requested.  As he mentions above, the issue occurs when erasing block 1 from within U-Boot (nand erase 20000 20000).   As mentioned earlier, our U-Boot is 3 blocks long. This causes the processor to hang.  Our question is, why doesn't it jump to the next U-Boot image? .  

    The dump of the memory locations 0xffff0700 - 0xffff0800 is all 0's

    The BOOTROM Info portion of the gel file shows a ROM Status code of 0x00000009 (see below).

    ARM9_0: GEL Output: ---------------------------------------------
    ARM9_0: GEL Output: | BOOTROM Info |
    ARM9_0: GEL Output: ---------------------------------------------
    ARM9_0: GEL Output: ROM ID: d800k008
    ARM9_0: GEL Output: Silicon Revision 2.1
    ARM9_0: GEL Output: Boot pins: 14
    ARM9_0: GEL Output: Boot Mode: NAND 8
    ARM9_0: GEL Output:
    ROM Status Code: 0x00000009
    Description:ARM9_0: GEL Output: Invalid AIS keyword
    ARM9_0: GEL Output:
    Program Counter (PC) = 0xFFFD45E0
    ARM9_0: GEL Output:

    --------------------------------------------------------------------

    Please let me know if you have any suggestions and/or need more information.

    Thanks!

    katrina

  • 0 in reply to Katrina Heiles
    TI__Guru** 116170 points

    Hi Katrina,

    Is it possible for you to share the NAND erase function from uboot at your driver code so that we can analyze the differences.

    The strange thing is" The dump of the memory locations 0xffff0700 - 0xffff0800 is all 0's". This region contains the global boot structure that would help us determine what NAND block it is booting from. Are you sure, you read this memory region after the device failed to boot. Can you confirm that this area is populated when the boot works.

    Regards,

    Rahul

  • 0 in reply to Rahul Prabhu
    Prodigy 70 points

    Hi Rahul,

    we don't have any mods to the nand erase function.  Therefore, I have attached a gzipped version of all our u-boot code, which is mostly from arago.

    Please note: I was wrong about those memory locations being all 0's - sorry about that.  I re-did the test and in the FAILED case the memory looks like this:

    in hung case
    from ccs memory browser, starting location: 0xffff0700

    00010900 08000500 00000000 000E0000
    00000003 00000000 00000000 00000000
    00000003 00000000 00000000 00000000
    00000004 00000000 00000000 00000000
    00000000 FFFFFFFF 00000000 00000000
    00000000 00000000 00000000 00000000
    FFFD7400 FFFD768C 00000000 FFFD7BA8
    00000000 FFFD15D0 00000000 FFFD45B0
    FFFF07A0 00000000 00000000 00000002
    FFFF1000 00000004 00000004 000007FC
    62000000 FEDC2C01 00001000 00060040
    000B0800 02000040 02040010 00010103
    D0BB0001 00000002 3FE50001 FFFD91C4
    FFFD921C FFFD923C FFFD90D4 0AA97ECC
    1F5EAF90 BF6F9E4D B4A22B4B 38F9EA52
    513EC44A 5015B4B1 92EACEA1 F9C19B13
    F69D5C77 CFF9329B 7C1CC3B7 C051FBA4
    3EB5422E

    In the normal case, memory at that location looks like this:

    from ccs memory browser, starting at location 0xffff0700

    00010003 08000500 00000000 000E0000
    00000003 00000000 00000000 00000000
    00000003 00000000 00000000 00000000
    0004F758 00000000 00000000 00000000
    C1080000 FFFFFFFF 00000000 00000000
    0000004C 00000000 00000000 00000000
    FFFD7400 FFFD768C 00000000 FFFD7BA8
    00000000 FFFD15D0 00000000 FFFD45B0
    FFFF07A0 00000000 0000001E 00000003
    FFFF1000 0004F758 00000758 000000A8
    62000000 DEDC2C01 00001000 00060040
    000B0800 02000040 02040010 00010103
    D0BB0001 00000003 3FE50001 FFFD91C4
    FFFD921C FFFD923C FFFD90D4 02A97FCC
    0F5E2F90 BF6F9C4D B4A22B5B 38F9EA52
    503AC45A 5117F4B1 B2EACEA1 F9C19B13
    F69D5C77 CFF9329B 7C1CC397 D051F3A1
    3EB5422E

    u-boot_code.tar.gz
  • 0 in reply to Katrina Heiles
    Prodigy 70 points

    Hi Rahul,

    Were you able to learn anything from the information provided?  Please let me know if you have any suggestions or need more information

    thanks for your help!

    katrina