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 slow to execute - Stuck in copy_decompress_rle.obj

I am working on booting a 6678 DSP which is installed on a custom board via SRIO and it is currently taking 45 seconds to start executing our boot code after writing Core0's  Boot Magic Address.

Here is the test sequence  / debug steps I am running using the srioboot_ddrinit.bin file provided with the MCSDK

- Connect debugger to Core0 in no-boot mode

- Transfer boot program to core 0 L2SRAM

 -Verify with CCS that all boot code successfully transferred over SRIO

- Write Core0 Boot Magic Address from Host via SRIO

- Verify Boot Magic Address is set correctly using CCS

- Load Debug Symbols via CCS and set a breakpoint on the first line of Main()

- Allow Core0 to start executing.

At this point it consistently takes about 45 seconds to reach the first line of Main(). If I then let the Core0 execute for anywhere from a couple seconds up to 30+ seconds and halt Core0 what I see is the program counter looping over a small address range in the vicinity of 0x1080ab80, which according to the .map file corresponds to copy_decompress_rle.obj

What could be wrong that would cause the RBL to spin in the copy_decompress_rle function for 40 seconds? It does eventually exit and boot successfully. One thing worth noting is that our DSP is setup to be Big Endian, and I see that the srioboot example is Little Endian. I believe that the Endian difference is  accounted for in srioboot_ddrinit_elf2HBin.bat but I wanted to mention that in case it could be related. Our Boot code must have the right Endianess as when main() does eventually run, it runs correctly, I would expect it to not boot at all if the code endianness was incorrect.

  • Hi John Connors,

    I understand you are running on Custom boards, please run the custom board on SRIO boot mode not on "No boot" mode.

    What is the silicon version used on the custom board?

    Have you loaded the IBL on the board?

     Are you able to run the SRIO boot example successfully on EVM or not? Recently, we have run this example and here is the post for your reference.

    https://e2e.ti.com/support/dsp/c6000_multi-core_dsps/f/639/t/456577#pi316458=2

    Regarding endian support, all of our examples has been validated only on little endian mode. The SRIO host loader needs to be updated and re-compiled for Big endian support. Please refer the srioBootExample.c for more information.

    Thank you.

  • Hi John Connors,

    You must set up the custom board on SRIO boot mode before transferring the boot code over SRIO. Please refer KeyStone Architecture DSP Bootloader User Guide for the RBL initialization process during SRIO bootloader operation.

    Please get back to us if you have above issue with ROM SRIO boot. Thank you.
  • Sorry Raja, but I believe I misspoke in my original post. We do have our DSPs setup in the SRIO Boot Mode and are getting a Port OK at power on, and are not having any SRIO communication problems with the bootloader at this time.

    When I said " Connect debugger to Core0 in no-boot mode" what I really meant was I was connecting the debugger only but not loading a program. If there is any additional info I can collect to help investigate just let me know.

    To summarize, what I am seeing is the DSP Program counter looping in copy_decompress_rle.obj for about 40 seconds before entering our Main() after writing the boot magic address.
  • Thank you for the clarification.

    1. I understand that you are running MCSDK pre-built image for SRIO boot(srioboot_ddrinit). How about  SRIO host , is it pre-built image from MCSDK or host application developed by you?

    2. We have experimented SRIO boot only with pre-built images of MCSDK on EVM don't see any issue. I will run the example again with host application changes discussed on other thread and get back to you with my observation.

  • Hi John Connors,

    Please ignore above question as I am able to find the root cause for the issue. Please find my observation's below.

    1. The srioboot_ddrinit calls the platform specific initialization routine which is written for TI EVM's not for custom boards. In order to use this example, you need to initialize the custom board design(platform_init()) so you can not use sriboot_ddrinit example directly on custom boards.

    2. I am able to boot SRIO successfully with the changes on host loader with TI EVM's.

    Thank you.
  • Raja,

    We have a custom platform build for our primary application, unfortunately that custom platform uses DDR3 for some memory regions which will will not be accessible until DDR is initialized.

    How does TI normally recommend developers handle this? Do we need to create two custom platform packages one for our full application and a second for the bootloader that does not rely on DDR? My long term plan is to migrate our SRIO Bootloader to flash memory (once it works) so have it initialize DDR memory, configure SRIO in a mode that is not selectable with the boot pins and power on, after which we will full application over SRIO in the same manor as the hello world boot example.

  • Hi John Connors,

    No. I am not talking about the RTSC platform file which splits memory sections for target application.

    The platform init means board specific(EVM) initialization. The platform_init routine does the following,

    1. Initialize PLL Controller(PA & DDR)
    2. Initialize DDR Controller
    3. Initialize the power domains.
    4. Enable Error Correction for memories.

    Please refer function platform_init() at ~\pdk_C6678_1_1_2_6\packages\ti\platform\evmc6678l\platform_lib\src\platform.c

    Thank you.
  • Thank you for the feedback. Can you point me to the TI document that describes creating a custom platform library?

    I will give this a try, but am not convinced it will solve our problem. The 40second delay we are seeing happens before main() is invoked and platform_init() is called. Would just linking in the EVM platform lib be enough to cause problems prior to the RBL jumping to main()?
  • Raja,
    After making some changes to our SRIO Bootloader this problem appears to be resolved and the DDRInit boot is taking about 1sec or less.

    I would still like a reference to any custom platform library documentation to make sure that we are accounting for everything we need to. If you could point me to that, I will mark this thread as verified in the near future. Many thanks for the help.
  • Hi John Connors,

    Great !!! Can you please describe your changes to SRIO bootloader or attach the source code so that we can support better in future?

    I do not know weather we have custom library documentation however i will guide you to modify/port the platform library for custom board.

    1. The platform_init() does the work of gel file in code. Please compare the initialization section of MCSDK gel file and platform_init() in platform lib.

    2.  I hope, you have updated gel file for custom board. You can use the same values to update the platform lib for custom boards and rebuild the PDK.

    http://processors.wiki.ti.com/index.php/Rebuilding_The_PDK#Building_PDK_using_gmake_in_Windows_environment

    Thank you.

  • Raja,
    What I did for my quick test today was to remove the platform lib from the projects include and linker paths. I then replicated the GEL functionality that was previously updated for our board in the SRIO Bootloader. Are there any downsides to just running the PLL and DDR init sequences and not having a platform library included at all?
  • Raja,
    Now that our SRIO Bootloader is working, I have one last bootload related task that I need to do. I have read everything in the bootloader documentation and cannot find any detail about how to go about creating a EMIF16 binary image.

    I have tried the suggestions in e2e.ti.com/.../367102 but the resulting .bin file I get is almost entirely filled with zeros, and our _c_int00 entry point is not at the beginning of the file. Since _c_int00 needs to be located at 0x70000000 for a EMIF16 boot, ad we place our bin file at 0x70000000 I would have expected code to located at beginning of the file.

    Could you please point me to the correct documentation that describes creating this boot format? A Sample EMIF16 boot program similar to the SRIO boot one would be even better.
  • Hi John Connors54,

    We are glad that the issue got resolved. However, Could you please help me with the solution for SRIO boot issue? either source or steps or both?

    Please help us to close this ticket and regarding EMIF 16, I would recommend you to start a new thread with your questions.

    Thank you.
  • By default all code I write at work is marked as Company Proprietary, so I cannot post complete source on the internet. What I changed to get things working was to remove the platform lib entirely and replicate the same boot sequence my EE's have previously updated in our GEL file.
  • Hi John,

    Thank you for confirming the issue with platform specific initialization.

    I was expecting some other solution because of your below post,

     

    https://e2e.ti.com/support/dsp/c6000_multi-core_dsps/f/639/p/468405/1684509#1684509

    Raja,

    After making some changes to our SRIO Bootloader this problem appears to be resolved and the DDRInit boot is taking about 1sec or less. 

    Thank you.