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

6670 I2C Boot Config Table -> Boot Tables

Erick Higa
Intellectual 860 points

I'm having an issue booting from I2C trying to do a boot config then trying to go to a normal boot table boot.

The boot parameter table is setup to boot a config table, then go to the boot table.

I have tested the modes independently, and if my primary boot parameter table is set to Boot Mode1 (Boot Tables) it boots fine, but if it is set to Boot Mode 1 (Boot Config Table), I can't seem to point it to the secondary parameter table properly (since I've checked that the config tables load fine and change the values of the appropriate locations).

In the primary table (when trying to set to config tables first) I set Next Dev Addr to 0x100 (the address of the second parameter table, and Next Dev Addr Ext to 0x51 (the I2C address I'm booting from).  Is there anything else I am missing?

  • 0
    Intellectual 860 points

    Here is my eeprom's first 378 bytes. It boots fine if I have it boot from 0x0100 (using the boot pins), but not from 0x0000

    Primary Boot Parameter Table Boot Config Table Secondary Boot Parameter Table
    0000: 00 20 f9 9b 00 28 00 00 00 00 00 00 00 02 00 80
    0010: 00 51 00 00 00 04 00 64 01 90 01 00 00 51 02 00
    0020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    0030: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    0040: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    0050: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    0060: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    0070: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    0080: 00 58 9c 3b 10 88 00 00 ab cd 12 34 54 32 ed cb
    0090: 10 88 00 04 ff ff ff ff 00 00 00 00 10 88 00 08
    00a0: 00 00 00 00 ff ff ff ff 10 88 00 0c 00 00 ff ff
    00b0: ff ff 00 00 10 88 00 10 aa aa 00 00 55 55 ff ff
    00c0: 10 88 00 14 00 00 55 55 ff ff aa aa 00 00 00 00
    00d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    00e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    00f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    0100: 00 20 f9 ed 00 28 00 00 00 00 00 00 00 01 01 80
    0110: 00 51 00 00 00 04 00 64 01 90 00 00 00 00 02 00
    0120: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    0130: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    0140: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    0150: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    0160: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    0170: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  • 0 in reply to Erick Higa
    Intellectual 860 points

    I've checked the Boot Parameter table in L2SRAM (@108F3680h) by hooking up the debugger after booting (in config table mode), and it still has the primary table in it.  That leads me to believe that it is not loading the secondary table.

    Are there any example binaries out there I could look at that boot I2C in config mode and then do a secondary boot?

  • 0 in reply to Erick Higa
    Intellectual 860 points

    Still waiting for any sort of answer.... Am I right that it is possible to boot into configuration table mode before going into regular boot tables?  If I am incorrect about this, I would like to know as soon as possible.

  • 0 in reply to Erick Higa
    TI__Genius 9915 points

    The second parameter table still points to the boot config table. Use the bootloader ug boot paramter table as reference. It is not clear what you are expecting. But if i am right in assuming, you want to do

    1. Boot parameter table to branch to boot table (Dev addr  to point to config boot table block and Dev next addr should point to the next boot parameter table)

    2. Boot config table at the dev addr.

    3. Boot parameter table at dev next addr( This will have dev addr to the boot table block)

    4. Boot table block at the dev addr in the second  boot parameter table.

    As you can see your two boot parameter tbale is pointing to the same boot config block.

    Please let me know if this works.

    Thanks,

    Arun.

  • 0 in reply to ArunMani
    Intellectual 860 points

    Hi Arun,

    Thanks for the response, that is exactly what I am trying to do.

    I'm not sure what you mean by both parameter tables pointing to the same boot config block, from the same config block, from table 3-19 in sprugy5a, the Boot Dev Addr is located at offset 14, if you look at my primary boot parameter table, I believe this address is 00 80 -> address 0x80, and my second table has it as 01 80 -> 0x180 (the address of my boot tables).  

    If I am wrong about that (based on my second post) can you be more specific of where I have this wrong?  I have loaded the contents of address 0x100 @address 0 and it boots fine (boot tables no configuration) using the boot tables @0x180, so I'm not sure where my error on this is.

  • 0 in reply to Erick Higa
    Intellectual 860 points

    Ok, I figured out what was "wrong", it was the fact that I calculate a checksum for the boot parameter tables.  Once I disabled the checksum (by setting it to 0), it started working (able to setup DDR3 using Configuration Tables, then load the application into DDR3 using Boot Tables).

    I figured this out using the Boot Parameter table in L2SRAM (@108F3680h), I noticed that I was wrong when I stated that it was exactly like the Primary Boot Parameter Table after the config was done, it was actually just like the Primary, except for the fact that the DevAddr was changed to the value of NextDevAddr, and the Option was set to 0 (Boot Parameter Table).  I figured out the bootloader was getting stuck there for some reason, and realized that since the checksum was changed to recalculate the changed values, the bootloader code would not see that as a valid parameter table and stop there.  Once I realized that, I changed the checksum value (in my primary table) to 0 to disable the checksum and it started working.

    I'm pretty sure that is what is going on, but would like it verified also.  There is nothing in the documentation that states this, in fact Table 3-18 in sprugy5a, does not clearly state that the checksum can be disabled.

  • 0 in reply to Erick Higa
    Intellectual 575 points

    Can someone at TI verify that this is the correct method in resolving this issue?  Thanks.

  • 0 in reply to Jimmy Fung
    Intellectual 860 points

    Arun or another TI employee,

    We would still like my findings considering Config Table mode and the checksum in the Parameter Table verified, if we go forward with this solution, we would like to know that this is the correct method that we should be doing.

    Thanks,

    Erick

  • 0 in reply to Erick Higa
    TI__Genius 9915 points

    Yes that is correct.

    Thanks,

    Arun.