Putting code in L1PSRAM

Using DaVinci's L1P region as non-cached program memory

Problem

On the DaVinci, the L1P memory region can be mapped as either cache, RAM or a combination of both. After restart, the L1P configuration register (L1PCFG) is configured to all-cache mode by default on the DM6446 (and other C64P-based devices. Refer to your device's Reference Manual to see the default cache setting in L1PCFG). The BIOS RTOS can be used to configure part or all of L1P into RAM. Here's a snippet of a BIOS 5 configuration (.tcf) file that shows how to configure all of L1P into program memory:

<syntaxhighlight lang='javascript'> prog.module("GBL").C64PLUSL1PCFG = "0k";

var L1PSRAM = bios.MEM.create("L1PSRAM"); L1PSRAM.len = 0x7000; L1PSRAM.base = 0x11E08000; L1PSRAM.createHeap = false; L1PSRAM.space = "code"; </syntaxhighlight>

Based on this configuration, BIOS modifies the cache configuration register in its boot code. However, by the time the boot code is executed, some code would already have been cached in the L1P area. Hence it is not advised to load code or initialized data into the L1P area as it has a chance to be overwritten before the cache mode is set.

This topic discusses how to leverage as program memory the RAM that becomes available when L1P is not configured as 100% cache.

Solution

To simplify things, the solution proposed makes use of copy tables (see spraa46 for details) to bring code into L1P. Assuming we want to bring some code myCode.obj into L1P, we can load the code into DDR and specify L1P as a run address in the linker cmd file:

.func1 { myCode.obj(.text) } load = DDR, run = L1PSRAM, table(_func1_copy_table)
.ovly > DDR

Then in the user code (e.g. main()), one can do the following

<syntaxhighlight lang='c'> extern void EDMACOPY_copy_in(COPY_TABLE *tp); extern COPY_TABLE func1_copy_table;

Void main (Int argc, Char * argv []) {

   // Bring the code from external memory to L1P
   EDMACOPY_copy_in(&func1_copy_table);

  ....

} </syntaxhighlight>

The EDMACOPY_copy_in() function shown here is used as an alternative to the copy_in() function provided by the RTS library in the code generation tools to bring the code section from external memory to L1P. This function uses the EDMA to perform the transfer instead of memcpy(). This approach is necessary because the L1P memory region cannot be written to by the CPU. EDMACOPY_copy_in() can be written by the developer by making use of the EDMA Low Level Driver shipped in the DVSDK. Taking a peek at the existing implementation for copy_in() in the file rts.src in the code generation tools should help you figure out how to work with the copy table structure passed into the function.