• State Resolved
  • Locked Locked
  • Replies 5 replies
  • Subscribers 54 subscribers
  • Views 3674 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.

how to remove the .bss from bin file

ge shuihuan
Intellectual 580 points


I am using CCS V5.2 for am335x development boards. I do not want to put the .bss section to .bin file. When i used the ADS1.2 to compile my project , it was about 3.5MB of the bin file. But when i change the project to CCS , it's bin file comes to 47.2MB. So, i check the .map file , and find that the .bss take over about 43.8MB. The following is my map:

and my cmd file is :

MEMORY
{

DDR_MEM: o = 0x80400000 l = 0x7FFFFFF /* 128MB external DDR Bank 0 */

}

SECTIONS
{

.init : {
init.obj(.text)
} load > 0x80400000

.text : > DDR_MEM /* CODE */
.data : > DDR_MEM /* INITIALIZED GLOBAL AND STATIC VARIABLES */

/* UNINITIALIZED OR ZERO INITIALIZED GLOBAL & STATIC VARIABLES */
.bss : > DDR_MEM
RUN_START(bss_start)
RUN_END(bss_end)

.cio : > DDR_MEM
.const : > DDR_MEM
.switch : > DDR_MEM
.far : > DDR_MEM
.args : > DDR_MEM
.ppinfo : > DDR_MEM
.ppdata : > DDR_MEM

/* TI-ABI or COFF sections */
/*.pinit : > DDR_MEM*/
/*.cinit : > DDR_MEM*/

/* EABI sections */
/*.binit : > DDR_MEM*/
/*.cinit : > DDR_MEM*/
.init_array : > DDR_MEM /* contains global constructor tables */
.neardata : > DDR_MEM
.fardata : > DDR_MEM
.rodata : > DDR_MEM
.c6xabi.exidx : > DDR_MEM
.c6xabi.extab : > DDR_MEM

.sysmem : > DDR_MEM /* heap */
.stack : > DDR_MEM /* SOFTWARE SYSTEM STACK 0x87FF7FFF */

}

how can i cut off the .bss from my bin file ?

  • 0
    TI__Guru**** 251300 points

    Are you sure you don't need the .bss section (and other uninitialized sections) in the .bin file?  

    How do you create your .bin file?

    Thanks and regards,

    -George

  • 0 in reply to George Mock
    Intellectual 580 points

    Tks for reply!

    yes，because the .bss is too big and take many space of flash space .  But i want a symbol that indicates the the start addr and the end addr of the .bss sections, as I can use that to initialize the .bss section in the memory on the boot routine.

    how can i deal with it?

    I use the post-build cmd ""${CCS_INSTALL_ROOT}/utils/tiobj2bin/tiobj2bin.bat"  "${ProjName}.out"  "${ProjName}.bin"  "${CG_TOOL_ROOT}/bin/ofd470.exe"  "${CG_TOOL_ROOT}/bin/hex470.exe"  "${CCS_INSTALL_ROOT}/utils/tiobj2bin/mkhex4bin.exe"" to creat the bin file.

  • 0 in reply to ge shuihuan
    TI__Guru**** 251300 points

    I have a solution to suggest.  I'm confident it will work, but I can't easily verify it.  

    In your linker command file, add the HIGH location specifier to the allocation of the .bss section ...

    .bss > DDR_MEM (HIGH)

    This will cause .bss to be allocated to the highest address within the DDR_MEM memory range.

    When tiobj2bin processes the .out file into the .bin file, uninitialized sections like .bss are skipped over.  Since .bss, in terms of its address, is highest of all, it effectively gets ignored completely in the conversion to .bin.  And thus your .bin file is smaller by the size of the .bss section.

    Using the HIGH specifier is actually a bit too much for this particular situation.  You don't strictly need .bss to be at the highest possible address in DDR_MEM.  Rather, you need it to be the last section in DDR_MEM.  But, I think this distinction is of no importance to you.

    Thanks and regards,

    -George

  • 0 in reply to George Mock
    Intellectual 580 points

    Tks very much!

    The way you mentioned is actually effective. Then it reminds me another way to solve this problem. The following is the way:

    SECTIONS
    {

    .init : load = 0x80000000
    {
    init.obj(.text)
    }
    .text : load = DDR_MEM /* CODE */
    .data : load = DDR_MEM /* INITIALIZED GLOBAL AND STATIC VARIABLES */
    .const : load = DDR_MEM

    /* EABI sections */
    /*.binit : > DDR_MEM*/
    .cinit : load = DDR_MEM /* only created by use --rom_model */
    .init_array : load = DDR_MEM /* contains global constructor tables */
    .rodata : load = DDR_MEM
    .neardata : > DDR_MEM
    .fardata : > DDR_MEM

    GROUP
    {
    /* UNINITIALIZED OR ZERO INITIALIZED GLOBAL & STATIC VARIABLES */
    .bss : > DDR_MEM
    RUN_START(bss_start)
    RUN_END(bss_end)
    .sysmem : > DDR_MEM
    }
    .stack : > DDR_MEM(HIGH)
    }

  • 0 in reply to ge shuihuan
    TI__Guru**** 251300 points

    I'm glad this works for you.  But I am concerned that this works more out of happenstance than anything else.

    This wiki article gives some good background.  

    This syntax ...

    ge shuihuan said:
    GROUP
    {
    /* UNINITIALIZED OR ZERO INITIALIZED GLOBAL & STATIC VARIABLES */
    .bss : > DDR_MEM
    RUN_START(bss_start)
    RUN_END(bss_end)
    .sysmem : > DDR_MEM
    }

    has 2 problems.  For one thing, I think you have uncovered a bug in the linker.  It should not be possible to allocate members of a GROUP, just as you have allocated both .bss and .sysmem to DDR_MEM.  Normally, you only specify an allocation for the entire GROUP ...

    GROUP > DDR_MEM
    {
        /* list output sections here */
    }

    Secondly, this GROUP only guarantees that .bss and .sysmem will be next to each other, in that order.  You want them to be the last sections before .stack, and I suspect you are getting that.  But GROUP does not guarantee that placement.

    If you are happy with how things are working, I can understand your reluctance to change things further.  But I think it is important that I point out potential pitfalls.

    Thanks and regards,

    -George