• State TI Thinks Resolved
  • Locked Locked
  • Replies 9 replies
  • Answers 2 answers
  • Subscribers 100 subscribers
  • Views 1482 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.

Debug IBL and EEPROM

Brian Li
Intellectual 430 points

Other Parts Discussed in Thread: TCI6638K2K

 

Hi experts,

 

My setup:

Board: EVMK2H Rev 40.

MCSDK: MCSDK_bios_3_01_04_07

1. What are differences between binary file of the IBL and binary file of the boot image?

  

2. How can I debug EEPROM efficiently?

    Whether does RBL access EEPROM correctly?

    Whether does  EEPROM wake up  IBL ?

    Whether can  RBL run  IBL correctly?

     Thanks!

 Regards,

 Brian

 

 
  • 0
    TI__Guru* 81335 points
    Brian,
    1. What are differences between binary file of the IBL and binary file of the boot image?

    My understanding is that, both are boot image used to boot the devices from the selected boot mode whereas IBL will have some additional capabilities to boot the device.
    Please refer MCSDK 2.x user guide for more information about IBL. Thank you.
  • 0
    TI__Guru** 116830 points
    Hi Brian,

    The IBL component was relevant only for Keystone I devices as it was introduced to provide a work around for the PLL initialization sequence issue mentioned int he C6678 and C6670 and then extended to provide more functionality.

    Keystone II device BootROM doesn`t have this issue, so you don`t need a secondary bootloader unless, you find any features missing in the bootROM. Keystone II devices are also primarily ARM boot devices.

    For creating and booting images for Keystone II devices , you refer to the Keystone II Boot examples that we provide here. They also contain exaamples to boot using I2C EEPROM.

    processors.wiki.ti.com/.../KeystoneII_Boot_Examples

    Hope this helps.

    Regards,
    Rahul
  • 0 in reply to Raja
    Intellectual 430 points

    Thank you!

    please tell me the answer about Q2.

  • 0
    TI__Guru** 116830 points

    Is your question regarding DSP boot master or ARM boot master use case.

    The simplest way to debug the EEPROM would be to create a image for the EEPROM and flash it. Then do a CPU reset and configure DEVSTAT to I2C boot mode and let the RBL run set hardware break point at boot_ROMexit function (For DSP this is address 0x20b0bb8c and for ARM it is 0x0000bd8c).

    Now you can check to see if the boot parameter table(check datasheet for address) for I2C boot is populated correctly. Also look to see if the application binary(IBL) loaded in MSMC ? Other than this you can hook up a scope on the data and address lines of the I2C to make sure that there is activity on the lines at the time of boot. After bootExit if you single step, you should be in the IBL code after ROM completes the exit function.

    If didn`t hit the exit function then you may have a issue with your setup either boot parameter table is not populated correctly or you have some issue with your hardware hook up. I would recommend that you start with the I2C boot examples that we have tested and provided on the wiki to check your EVM setup and then create your own image.

    Regards,

    Rahul

    PS:

    Note I2C boot on K2H device runs in PLL bypass mode so the ROM will take significant amount of time to load the image so you will need to be patient especially if your boot image is large

  • 0 in reply to Rahul Prabhu
    Intellectual 430 points

    Hi , Rahul

     

    Thank you for your comment.

     Seriously, there are some reasons to we decide using DSP only boot. First,we have some legacy code of DSP.

    Second, the important cause is that the rest share memory of our EVMK2H are not enough to implement Arm+Linux Boot.

    Third,6638K2K can support DSP only Boot according the document, SPRS836D— TCI6638K2K 8.1.2 Boot Modes Supported.

     

    Our requirement is that we need to achieve 6MB boot image of Nand flash boot on EVMK2H.

     Can we use RBL to achieve Nand flash boot on EVMK2H?

    Need we develop IBL to initial Nand flash?

     

    Thank you!

    Regards,

    Brian

  • 0 in reply to Brian Li
    TI__Guru** 116830 points
    Yes, RBL on the DSP can boot the device using NAND flash so you don`t need a secondary bootloader(IBL) to boot from NAND flash as in case of older devices like C6678 and C6670.

    Only requirement is the NAND flash should be ONFI 1.0 compatible and must require only upto 4 bit ECC which the EMIF16 on K2H/K2K can support.

    Regards,
    Rahul
  • 0 in reply to Rahul Prabhu
    Intellectual 430 points

    Hi Rahul:

    I don't change any component on EVMK2H. Do I need to write  any code about ECC?

    Can we use RBL to achieve Nor flash boot on EVMK2H?

  • 0 in reply to Rahul Prabhu
    Intellectual 430 points

    There are two question to ask for you.

    How should I set hardware break point? Would you give me a document about that?

    Where is the “address 0x20b0bb8c” from? Would you give me the document?

  • 0 in reply to Brian Li
    TI__Guru** 116830 points

    Brian,

    Setting hardware break points is a Code composer Studio IDE debug feature. when you connect to the device, you can go to debug View -> Disassembly and right click on the memory location and choose to set the hardware break point.

    The address that I gave you is an address in the ROM  memory of the device which is the ROM_re-entry address. 

    Regards,

    Rahul