• State Resolved
  • Locked Locked
  • Replies 2 replies
  • Subscribers 98 subscribers
  • Views 467 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.

PRUSS vs EDMA vs dMax to boot the ARM on the OMAP L137

Louis Dupont
Intellectual 480 points

I installed OMAPL137_arm_setuplinux_1_00_00_11.bin and looked at the DSP ubl sources used to generate dsp-spi-ais.bin within

~/OMAPL137_arm_1_00_00_11/REL_LSP_02_20_00_07/PSP_02_20_00_07/board_utilities/dspubl

I've been a little a surprised by what I found in device.c. DEVICE_set_ARM_reset_vector (Uint32 address) appeared to use the dMax DMA Engine to transfert a small piece of boot code which will jump to the main executable as the DSP cannot access the ARM's dedicated RAM where the ARM starts its execution.

Weird thing is that dMax does not appear to be featured on the OMAP L137. So I investigated a little futher. First of all, there's a consensus saying that the dMax engine is featured on the OMAP L137, simply not supported nor documented for some reasons. Second, dspubl is not really using dMax but rather the Programmable Realtime Unit Subsystem (PRUSS) to perform this. 

However, many refer to the dMax and PRUSS as being the same thing. Beside the fact the PRUSS is refered to as dMax within the DSP ubl sources I can hardly see how one could get to that conclusion :

dMax : http://focus.ti.com/lit/ug/spru795d/spru795d.pdf
PRUSS : http://processors.wiki.ti.com/index.php/Programmable_Realtime_Unit_Subsystem

So basically it's my understanding that the PRUSS simply act as a DMA engine. Yet the process to make a DMA engine out of the PRUSS is a litlle messy (just look a the code and you'll see what I'm talking about). Basically my question is why not simply use the EDMA engine to do that? I'm just guessing through the comments over its machine code :

0x24000080, // Load ARM vector table address to r0
0x24ffffc0,
0x24000081, // Load ARM code address to r1
0x240000c1,
0xf500e182, // Read ARM code from *r1 to r2,...
0xe500e082, // Write ARM code from r2,... to *r0
0x79000000, // Self loop

that the PRUSS simply acts as a DMA engine but I might be wrong. The only reason I see to that would be that the DMA engine might inherit its memory access privileges from either the DSP or the ARM (depending on whom started it). If it's the case, does this also apply to the dMax engine?

If neither of the DMA engine (EDMA or dMax) can be used, is the PRUSS really the only mean to boot the ARM from the DSP? One would think there should be an easier and cleaner way to do that.

Finally, is there some sort of an application note somewhere on the subject? Thanks.

Louis

  • 0
    TI__Guru 62975 points

    Louis,

    The PRUSS core evolved from the DMAX module so there are internal references to it as DMAX.  As you have noticed, the PRUSS does not come with pre-canned DMA functions like DMAX does on C6727.  The primary reason PRUSS is used to initialize the ARM is because of write access.  EDMA does not have write access to the ARM RAM.  The attached pic is from the System Reference Guide.

    -Tommy

  • 0 in reply to tlee
    TI__Guru 68920 points

    Just to add a comment - the idea behind the above decision was to trade some additional complexity at boot time for extra integrity once the system is operational.

    By not allowing the DSP to directly access the ARM's  RAM - we've also made it a lot more difficult for the DSP applicaiton to 'run away' and corrupt the ARM's critical vector table which is stored in the on-chip ARM RAM.   The downside indeed is some extra complexity at boot time; since the PRU does need to be programmed in order to initialize the ARM's RAM.   But this is essentially hidden in the DSP bootloader and once the ARM has been bootstrapped; it can manage it's own RAM itself.