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.

Compiler: Cinit tables and compression

Tool/software: TI C/C++ Compiler

Hello,

I am currently using the TI compiler tools for the TDA2xx IPU M4 (version ti-cgt-arm_16.9.2.LTS).

When i tried to turn off cinit compression in order to save link and startup time (due to the compression / decompression processes) , i got an error saying i am exceeding available memory.

I don't understand how can that be - disabling compression should only increase the size of the ELF file and also with no compression tan there is no point of having the cinit table (except for zeroing .bss) so the actual memory should be even less.

Can you please help and explain?

Thanks

Guy

  • Disabling compression often increases the total amount of target memory used.  

    The information in the .cinit section includes the initialization data for sections like .data. To save space, this initialization data is compressed by default.  If you disable compression, then the size of the .cinit section increases, thereby increasing the overall amount of target memory used.

    That's a very brief explanation for a part of system startup that has many details.  For more background, I suggest you read the chapter titled Copy Tables and Variable Initialization in the C6000 EABI Application Report.  That document is for C6000, and not ARM.  But it is still useful.  The low level details are different on ARM, but the higher level descriptions are relevant.  And I'm not aware of a similar document written for ARM.

    Thanks and regards,

    -George

  • Hi,
    Isn't the whole point of the cinit table is to reduce the size of the ELF file (overlay uses their own tables). the target should have enough memory to contain the uncompressed data anyway.
    If compression if off than what is the point of having the cinit - why not load the data straight to its appropriate location instead of doing an extra copy (with the exception where you need to initialize to zero like in bss)?

    Can you explain the usage of the cinit when not using compression ?

    Thanks
    Guy
  • Guy Mardiks said:
    Isn't the whole point of the cinit table is to reduce the size of the ELF file

    No.  The use case in mind is systems that must boot up from a cold start, with no assistance from any external loader like CCS.  The .cinit section resides in FLASH (or ROM).  Startup code processes the information contained in .cinit to initialize read/write sections like .data.  Because these sections are read/write, they cannot be in FLASH, but must be in RAM.  

    Guy Mardiks said:
    the target should have enough memory to contain the uncompressed data anyway.

    This varies by system.  Some will have enough memory.  Others won't.

    Guy Mardiks said:
    why not load the data straight to its appropriate location instead of doing an extra copy

    That is how it works when the link uses the build option --ram_model, instead of --rom_model.  But systems that boot up from a cold start can't do that.

    Thanks and regards,

    -George

  • Hi,
    Thanks - I understood the logic/reason for the behavior

    Thanks
    Guy