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.

DSPLink Boot Modes

I'm working with the OMAPL137 EVM and I have an application that needs to make use of both the DSP and ARM cores.  Traditionally I would be implementing this on a dual processor system so the OMAPL137 has some appeal as it brings the two cores onto one part.   I'm working to understand the different modes/configurations of DSPLink (boot and no boot mode) and to decide which will work better for my application.    From my understanding boot mode is where the ARM side will boot the DSP side by sending the DSP executable through the link.  I believe the no boot mode is where the DSP side will boot the DSP application from flash without any interaction from the ARM core.  Assuming this is correct, are there any differences in how the two cores can communicate/function after they are both booted using either mode?  I assume the choice of no boot verus boot mode comes with tradeoffs.  What are the tradeoffs or limitations of each mode?  From my research there seems to be limited information on the no boot mode and I perceive most are using the boot mode.

 

Thanks

  • Tim,

    Multiple applications/processes on the GPP may wish to use the services provided by DSPLink to control and communicate with the DSP. DSPLink supports multiple boot modes to enable different use cases.
    DSPLink PROC module supports three different scenarios for DSP boot-loading:

                1. Normal Boot Mode: DSPLink loads and starts the DSP running

    • DSP_BootMode_Boot_NoPwr
    • DSP_BootMode_Boot_PwrDefault
    2. External Load Mode: DSPLink only starts the DSP running
    • DSP_BootMode_NoLoad_NoPwr
    • DSP_BootMode_NoLoad_Pwr
    3. External Load and Start Mode: DSPLink does not load or start the DSP running
    • DSP_BootMode_NoBoot

    In all modes, the application calls all DSPLink APIs for PROC module. DSPLink internally checks the boot mode and accordingly determines the correct action to be  taken for each API. For example, APIs PROC_load, PROC_start, PROC_stop need to be called even in External Load or External Load and Start mode.

    There is no trade off in the run time usage of DSPLink IPC mechanisms. The only difference is in the way and the sequence that the cores boot and the initial handshake using DSPLink API's before the run time usage of DSPLink API's begin.

    There is some description in the DSPLink programmer's guide. The DSPLink sample apps can also be updated to build for the No Boot mode at http://processors.wiki.ti.com/index.php/DSPLink_FAQs#How_should_I_update_the_COMPONENT_file_to_check_DSP_BOOTMODE_NOBOOT_NoBoot_option The samples give a programmatic example on initial handshake for the NoBoot mode.


    Deepali

  • Deepali,

    Thanks for your response; it is helpful to know that I can use either of the modes and the DSPLink runtime functions without any differences between the modes.  Is there any thing else we should consider before choosing a mode?  I assume that if we start with Normal Boot Mode and want to later change to External Load/Start (NOBOOT) mode that the change is achievable without much lost effort?


    Thanks

  • Tim,

    Your application design should drive which boot mode to choose?

    It is easy to start with normal boot mode and then transition to NoBoot mode.

    Deepali

  • Deepali,

    Good to know as I'm designing around the normal boot mode.  Coming from a traditional dual - processor design background my mindset was initially to go with NoBoot as I incorrectly thought there might be limitations with using the boot mode.  It is now my understanding that there are not any limitations to using either booting method so that the standard DSPLink boot mode should be sufficient for my application. What I don't understand is,  what are the specific application considerations where the best method would be NoBoot mode with the OMAPL137 part?  I just want to be sure I haven't missed anything that will cost me later.

    Thanks,

    Tim