• State
  • Locked Locked
  • Replies 6 replies
  • Subscribers 98 subscribers
  • Views 835 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.

relocation overflow using BUF in SARAM or SDRAM for c55

Kar Boon Oung
Prodigy 40 points

I am using c55xx platform and TI DSP/BIOS. I created a number of BUFs inside the TCF (located in SARAM and SDRAM) and a part of the code looks like this:

...
bios.BUF.create("BUF_SARAM_00001160");
bios.BUF.instance("BUF_SARAM_00001160").bufCount = 2;
bios.BUF.instance("BUF_SARAM_00001160").size = 1164;
bios.BUF.instance("BUF_SARAM_00001160").bufSeg = prog.get("SARAM");
bios.BUF.create("BUF_SDRAM_00000004");
bios.BUF.instance("BUF_SDRAM_00000004").bufCount = 2000;
bios.BUF.instance("BUF_SDRAM_00000004").size = 8;
bios.BUF.instance("BUF_SDRAM_00000004").bufSeg = prog.get("SDRAM");
...

I created own custom malloc function (link order replace the bios malloc) which accesses those buf by using extern command as follows:

extern BUF_Obj BUF_SARAM_00001160;
extern BUF_Obj BUF_SDRAM_00000004;

For C64xx, I could just declare extern far BUF_Obj. But since I am using C55 which has 64k boundary, there are several "relocation overflow" errors during linking. The number of relocation errors is equal to the number of BUF created in SARAM and SDRAM.

>>   error: relocation overflow occurred at address 0x000003a6 in DATA section
            '.cinit' of input file
            'X:\\ult\code\startup\Omap1710\Conf_Omap1710cfg.obj'.  The 22-bit
            relocated address 0x392f0c is too large to encode in the 16-bit
            signed field. You may need to add a mask to the assembly
            instruction or use other target specific assembly features if you
            really only need the lowest 16 bits of this symbol. Please see the
            section on Relocation in the Assembly User's Guide.

Is there a way to get around this? I read online that it is possible to use macro but does not show example or details.

Your help is greatly appreaciated. Thanks.

  • 0
    TI__Mastermind 30830 points

    Which version of BIOS are you using and are you using the "C55" target (ie small-code/small-data model)?

  • 0 in reply to Alan DeMars
    Prodigy 40 points

    Hi Alan,

    I am using BIOS version 5_41_09_34.

    For the TCF file, I selected "ti.platforms.h3omap1710" from the c55xx list. I tried to use large memory model but still getting the same error.

    Thanks,

  • 0 in reply to Kar Boon Oung
    TI__Mastermind 20805 points

    Is it possible to send a small test case that we can reproduce this locally?

    OMAP1710 supports "huge" model which supports full 23-bit addressing on the data side.   Would compiling for huge model be an option?   To do this, you need to change the compiler/linker options in the project and also change the setting in the BIOS configuration (bios.GBL.MEMORYMODEL = "HUGE" or some such).

     

    small model requires all data to be on single 16-bit page

    large model allows pointers to anything within the 23-bit memory, but individual objects must not span a 16-bit page

    huge model allows pointers to anything within the 23-bit memory, and allows objects to span a 16-bit page.


    Huge model was added at/around the time OMAP1710 was released and is also available in newer 55x devices.

    Regards,
    -Karl-

  • 0 in reply to Karl Wechsler
    Prodigy 40 points

    Hi Karl,

    I tried with huge memory model and get the error below:

    >> ERROR: Huge memory model not supported for CPU revisions 1 or 2
    >> ERROR: Huge memory model requires CPU revision 3 (Ex: -vcore:3)

    How do I check which revision is the OMAP 1710 chip (1710EZZG CU 02A19ZW YB) on my hardware? Is there any workaround before the huge memory model was available?

    Btw, I am using the template "ti.platforms.h3omap1710" when creating the TCF file. One more thing, I also have BUF created in DARAM which did not generate relocation overflow errors since the address range for DARAM is within 64K. Only the SARAM and SDRAM bufs complain with this error.

    I will try to see if I am able to duplicate this in a smaller test case.

    Regards,

  • 0 in reply to Kar Boon Oung
    TI__Mastermind 30830 points

    All of the OMAP1710-specific BIOS libraries (small, large, and huge) are built with the -vcore:3.0 compiler option because the 1710 55x core supports the more efficient addressing modes that -vcore:3.0 utilizes. I'm wondering if this is somehow factoring into the problem you're having. To inter-operate with our libraries properly, I think you need to add -vcore:3.0 to your application's compiler options.

    Just to clarify, we build our omap1710 C55_large libraries with these options:

        "-ml -vcore:3.0"

    and C55_huge libraries with these options:

        "--memory_model=huge -vcore:3"

    Alan

  • 0 in reply to Alan DeMars
    Prodigy 40 points

    Hi Alan,

    I tried the suggestion but did not help.

    To debug this, I created a small CCS project with only ust the TCF file in it and all the compiler sections (.text, .cinit, .bss etc) set to SDRAM. When I added a number of BUF to the TCF in SARAM and SDRAM, the build linking generated the same relocation overflow error. I did some trial and error by moving individual compiler sections back to DARAM. When .bss of the TCF is set back to DARAM, all the SARAM and SDRAM BUF relocation overflow errors are resolved. Could you please explain why the .bss section of the BUF needs to be in DARAM and why the error is complaining about cinit instead? Thanks.

    Regards,

    Kar Boon