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.

Memory placement of SrioDevice_init in DDR3

Hi,

I have been trying to off-load the initialization- and configuration-related functions to DDR3 in my project. Most of the time simply adding this to the code

#pragma CODE_SECTION(the_function_name, ".big_mem");

is enough to free up some space in L2SRAM, which is where .text is placed, according to my .cmd file:

SECTIONS
{
    .init_array  >       L2SRAM
    .text        >       L2SRAM
    .stack       >       L2SRAM
    .bss         >       L2SRAM
    .cinit       >       L2SRAM
    .cio         >       L2SRAM
    .const       >       L2SRAM
    .data        >       L2SRAM
    .switch      >       L2SRAM
    .sysmem      >       L2SRAM
    .far         >       L2SRAM
    .ppdata      >       L2SRAM
    .big_mem:       load >> DDR3
}

However, inspecting the memory map file when doing the above for the SrioDevice_init() function available in pdk_C6670_1_1_2_6/packages/ti/drv/srio/device/device_srio_loopback.c I see a lot of trampoline calls which seem to be eating a big chunk of my L2SRAM memory:

FAR CALL TRAMPOLINES

callee name               trampoline name
   callee addr  tramp addr   call addr  call info
--------------  -----------  ---------  ----------------
$.text:device_srio_loopback.obj$0x1c74  $Tramp$S$$CSL_PSC_isModuleResetIsolationEnabled
   0089ac74     802b7810     802b6828   device_srio_loopback.obj (.big_mem)
$.text:device_srio_loopback.obj$0x1c44  $Tramp$S$$CSL_PSC_disableModuleResetIsolation
   0089ac44     802b7820     802b6834   device_srio_loopback.obj (.big_mem)
$.text:device_srio_loopback.obj$0x160  $Tramp$S$$CSL_SRIO_GlobalDisable
   00899160     802b7830     802b6840   device_srio_loopback.obj (.big_mem)
$.text:device_srio_loopback.obj$0x1c8  $Tramp$S$$CSL_SRIO_DisableBlock
   008991c8     802b7840     802b6858   device_srio_loopback.obj (.big_mem)
$.text:device_srio_loopback.obj$0x28  $Tramp$S$$CSL_SRIO_SetBootComplete
   00899028     802b7850     802b6874   device_srio_loopback.obj (.big_mem)
                             802b6de8   device_srio_loopback.obj (.big_mem)

Most, if not all of these trampoline calls are for CSL_xxx_xxx functions, which are declared static inline in their corresponding .h files, so I don't understand how could they be placed in L2SRAM instead of DDR3.

Is there a way to  get this code to load in DDR3 without having to add #pragma's to the entire CSL library? I must be missing something.


Maybe the reverse path would be to specify that .stack and .text are to be placed in DDR3 instead, and then use #pragma's only for speed-critical code, placing them in L2SRAM. How should I do it in this case? Should I put any other sections in DDR3 too?

  • There are other techniques for collecting input sections together into output sections.  The one most relevant here is covered in the section titled Specifying Library or Archive Members as Input to Output Sections in the C6000 assembly tools manual.  However, there is a mistake in the example in that section.  Every '=' should be replaced with a space.  In your case, write something like ...

        .csltext  { -l csl_library_name(.text) } > DDR3
    

    Thanks and regards,

    -George

  • I had done something similar in my .cmd after posting the question:

    .big_mem: {
        device_srio_loopback.obj(.text)
        *(.big_mem)
    }               load >> DDR3

    It seems to work, but I believe I am approaching this the wrong way. Please help me understand:

    I was under the impression that, because my project calls #include <csl_something.h>, which is full of one-liner functions declared static inline, no code was being generated specific for that CSL "library", and any usage of those functions would generate code in the memory section of the code that was calling it. In my case, SrioDevice_init -- which should be entirely in DDR3 since I used the CODE_SECTION pragma to put it in .big_mem --, had trampoline calls for functions in L2SRAM.

    Then, in functions that were NOT placed in DDR3 (i.e. the speed-critical part of my project), in which I also use some of those CSL functions, the CSL code would be generated *again*, this time in L2SRAM.

    Right now I don't really care about the extra code size that re-generating CSL code implies, but the behavior of the compiler/linker seems to be different: it will put the CSL code in one place and jump to it whenever necessary.

    I believe this is the case because (1) a .text section is being created for the device_srio_loopback.c file, whose only code is inside SrioDevice_init(); and (2) from your suggestion to extract the .text section from the 'csl library', which in this specific case I don't actually think exists (there are .c files in the CSL codebase, but the functions I use are from the aforementioned inline functions in .h files).

    So, while loading device_srio_loopback.obj's .text section in .big_mem does seem to work, won't I be creating an unwanted side-effect, that is, won't the CSL code now be placed in DDR3? I will try to investigate that further by debugging with assembly-step-into the relevant part, but an authoritative and informative answer by TI would be very welcome.


    Thanks for your help

  • I should have read your first post more closely.  I focused on the wrong thing.

    You expect the CSL functions which are supplied in a header file and marked static inline to be inlined.  But they are not.  There are two reasons this might happen.

    First, the most unlikely reason ... You fail to include the proper CSL header file(s) in the source code which calls these functions.  Such a mistake results in a diagnostic similar to ...

    "file.c", line 9: warning: function declared implicitly

    If this is not clear enough, add the option --verbose_diagnostics to see ...

    "file.c", line 9: warning: function declared implicitly
         has_no_declaration(arg1, arg2);
         ^

    Second, the more likely reason ... Inlining occurs only when you build with optimization, i.e. you use --opt_level=0 or above.  Otherwise, a normal function call is placed to an out-of-line implementation of that function.  That implementation is often supplied in a library.

    So, are you building with optimization?

    Thanks and regards,

    -George 

  • Ah, that was it. I was building the Debug configuration and no optimizations are specified.

    Using a Release configuration and reverting to

      .big_mem:       load >> DDR3

    in my .cmd file did the trick: I no longer get those trampolines generated. Thanks a lot.