CCS/TMS320C6678: Code Optimization and output sizesd

jameel magzal

Part Number: TMS320C6678

Tool/software: Code Composer Studio

Hello,

I'm trying to reduce the size of my output files to be able to use them in the boot loading process of the C6678EVM, The code was originally for the c6474 DSP and we ported it to the C6678, however i was looking at the output files before the porting and the sizes where something like 100-200kB , after the porting i get 4000k+, where does this size come from ? the only difference in the projects is the use of IPC notify(after porting) and disabling it reduces the file size by only 500kB.

Tried different build configurations, and using --symdebug:none, reduced the output size from 6000k to 3900k, but still i need it closer to the original size 100-200k

Also using strip6x utility works in reducing the files size really well, however when i try to use the files with hex6x mergebtbl bconvert64x

and bootpacket , the end filoe .eth is exactly the same size as if i did not use the strip utility

I would appreciate any help,

Thanks

Jameel Magzal

over 6 years ago

0 George Mock over 6 years ago

TI__Guru**** 249680 points

Please read the short article A Brief History of TI Object File Formats. Focus on the sub-part titled Comparing Sizes. At this point, we don't know which part of your executable object files is growing so much. The binary bits loaded to system memory, or the additional information. Or, maybe both.

Please compare the sizes of just the binary bits. Focus on the sections which contain the executable code, which are usually named .text. In most cases, the data does not change much, and I presume that is the case here. You can compare by inspecting the linker map files, or by using the utility sectti from the cg_xml package. Let me know what you find.

Thanks and regards,

-George

0 jameel magzal over 6 years ago in reply to George Mock

Intellectual 810 points

Hi George,

Thanks for the fast reply

I checked with sectti and i got these results

The old DSP file gives this information :

************************************************************
Name : Size (dec) Size (hex) Type Load Addr Run Addr
-------------------- : ---------- ---------- ---- ---------- ----------
.csl_vect : 512 0x00000200 CODE 0x118e4c00 0x118e4c00
.clk : 12 0x0000000c UDATA 0x118968f4 0x118968f4
.swi : 264 0x00000108 UDATA 0x118e4e00 0x118e4e00
.tsk : 192 0x000000c0 UDATA 0x118e4f08 0x118e4f08
.idl : 16 0x00000010 UDATA 0x118bc430 0x118bc430
.idlcal : 16 0x00000010 UDATA 0x118ca5e4 0x118ca5e4
.bss : 4353 0x00001101 UDATA 0x118dec88 0x118dec88
.hwi_vec : 512 0x00000200 CODE 0x118e5000 0x118e5000
.far : 186040 0x0002d6b8 UDATA 0x11800100 0x11800100
.mem : 4 0x00000004 UDATA 0x1182d7bc 0x1182d7bc
.bios : 17984 0x00004640 CODE 0x118c5f40 0x118c5f40
.cio : 288 0x00000120 UDATA 0x118e4a30 0x118e4a30
.pinit : 20 0x00000014 DATA 0x118968e0 0x118968e0
.sys : 16 0x00000010 UDATA 0x118dffd4 0x118dffd4
.text : 178496 0x0002b940 CODE 0x1182d7c0 0x1182d7c0
.cinit : 15692 0x00003d4c DATA 0x118d6240 0x118d6240
.switch : 1160 0x00000488 DATA 0x118e4074 0x118e4074
.gblinit : 100 0x00000064 DATA 0x118ca580 0x118ca580
.sysinit : 1408 0x00000580 CODE 0x118e3600 0x118e3600
.trcdata : 12 0x0000000c DATA 0x118ca5f4 0x118ca5f4
.rtdx_text : 4032 0x00000fc0 CODE 0x118e2000 0x118e2000
.TSK_idle$stk : 1024 0x00000400 UDATA 0x118e4500 0x118e4500
.initTask$stk : 10000 0x00002710 UDATA 0x118d9f90 0x118d9f90
.LOG_system$buf : 256 0x00000100 UDATA 0x118e5200 0x118e5200
.logTrace$buf : 4096 0x00001000 UDATA 0x118e0000 0x118e0000
.trace$buf : 256 0x00000100 UDATA 0x118e5400 0x118e5400
.rtdx_data : 1268 0x000004f4 UDATA 0x118e3b80 0x118e3b80
.pip0 : 20480 0x00005000 UDATA 0x118bc440 0x118bc440
.pip1 : 24000 0x00005dc0 UDATA 0x118b6660 0x118b6660
.pip2 : 36800 0x00008fc0 UDATA 0x1188d920 0x1188d920
.pip3 : 34000 0x000084d0 UDATA 0x1189ef60 0x1189ef60
.pip4 : 34400 0x00008660 UDATA 0x11896900 0x11896900
.pip5 : 16128 0x00003f00 UDATA 0x118ca600 0x118ca600
.pip6 : 16064 0x00003ec0 UDATA 0x118ce500 0x118ce500
.pip7 : 4096 0x00001000 UDATA 0x118e1000 0x118e1000
.pip9 : 4 0x00000004 UDATA 0x118dfff0 0x118dfff0
.pip10 : 28800 0x00007080 UDATA 0x118af5e0 0x118af5e0
.pip11 : 16000 0x00003e80 UDATA 0x118d23c0 0x118d23c0
.pip12 : 84000 0x00014820 UDATA 0x11879100 0x11879100
.pip13 : 19200 0x00004b00 UDATA 0x118c1440 0x118c1440
.pip15 : 33200 0x000081b0 UDATA 0x118a7430 0x118a7430
.hst1 : 16 0x00000010 UDATA 0x118bc420 0x118bc420
.hst0 : 256 0x00000100 UDATA 0x118e5300 0x118e5300
.hst : 60 0x0000003c UDATA 0x118e4b50 0x118e4b50
.log : 72 0x00000048 DATA 0x118dff8c 0x118dff8c
.pip : 1600 0x00000640 UDATA 0x118e2fc0 0x118e2fc0
.sts : 304 0x00000130 DATA 0x118e4900 0x118e4900
.const : 4577 0x000011e1 DATA 0x118ddaa0 0x118ddaa0
.args : 4 0x00000004 DATA 0x1182d7b8 0x1182d7b8
.trace : 512 0x00000200 DATA 0x118dfd8c 0x118dfd8c
.stack : 5120 0x00001400 UDATA 0x118dc6a0 0x118dc6a0
.L2RAM$heap : 131072 0x00020000 UDATA 0x11859100 0x11859100

------------------------------------------------------------
Totals by section type
------------------------------------------------------------
Uninitialized Data : 713397 0x000ae2b5
Initialized Data : 22453 0x000057b5
Code : 202944 0x000318c0

The c6678 File :

Name : Size (dec) Size (hex) Type Load Addr Run Addr
-------------------- : ---------- ---------- ---- ---------- ----------
.init_array : 4 0x00000004 DATA 0x0084caa4 0x0084caa4
.stack : 4096 0x00001000 UDATA 0x008582f8 0x008582f8
.bss : 17 0x00000011 UDATA 0x008596f8 0x008596f8
.neardata : 153 0x00000099 UDATA 0x0085970c 0x0085970c
.rodata : 16 0x00000010 UDATA 0x008597a8 0x008597a8
.cinit : 2568 0x00000a08 DATA 0x00859a00 0x00859a00
systemHeap : 204800 0x00032000 UDATA 0x00800000 0x00800000
.coreOnlyData : 221912 0x000362d8 UDATA 0x80704000 0x80704000
.vecs : 512 0x00000200 CODE 0x00859800 0x00859800
.text : 283296 0x000452a0 CODE 0x0c300000 0x0c300000
.const : 23958 0x00005d96 DATA 0x00850c40 0x00850c40
.fardata : 6428 0x0000191c UDATA 0x008569d8 0x008569d8
.switch : 732 0x000002dc DATA 0x008592f8 0x008592f8
.far.1 : 109220 0x0001aaa4 UDATA 0x00832000 0x00832000
.far.2 : 16792 0x00004198 UDATA 0x0084caa8 0x0084caa8
.cio : 288 0x00000120 UDATA 0x008595d8 0x008595d8

------------------------------------------------------------
Totals by section type
------------------------------------------------------------
Uninitialized Data : 563722 0x00089a0a
Initialized Data : 27262 0x00006a7e
Code : 283808 0x000454a0

I don't see that much difference in size, even though the out file says its 4.3MB(new) compared to 1MB(old), I think it's only due to the debug information?

after strip utility i get 620KB(not sure if this is reasonable)

the thing is i have 8 files like this and i do the following using the utilities :

hex6x app0.rmd
hex6x app1.rmd
hex6x app2.rmd
hex6x app3.rmd
hex6x app4.rmd
hex6x app5.rmd
hex6x app6.rmd
hex6x app7.rmd
mergebtbl core0.btbl core1.btbl core2.btbl core3.btbl core4.btbl core5.btbl core6.btbl core7.btbl app.btbl
bconvert64x -le app.btbl app.le.btbl
bootpacket app.le.btbl app.eth

And app.eth is 13MB and i cant use it for booting the dsp

0 George Mock over 6 years ago in reply to jameel magzal

TI__Guru**** 249680 points

Your code size increased about 40%. If that is due to the code having more features and capability, then such an increase might be expected. But if the features and capability are the same, then this should probably be investigated.

Even so, that does not explain ...

jameel magzal said:
the out file says its 4.3MB(new) compared to 1MB(old)

That is probably due to the debug information. To be more specific, I need you to submit both out files for inspection. Whether to submit them or not is up to you. If so, please put them both in a zip file and attach the zip file to your next post.

It is becoming apparent, though not certain, that the problem has more to do with these utilities ...

jameel magzal said:
mergebtbl core0.btbl core1.btbl core2.btbl core3.btbl core4.btbl core5.btbl core6.btbl core7.btbl app.btbl
bconvert64x -le app.btbl app.le.btbl
bootpacket app.le.btbl app.eth

These utilities do not come from the compiler development team. Unfortunately, I cannot help you with them. I suspect they are from a Software Development Kit (SDK) you use. What SDK do you use? I'll notify that team about this thread.

Thanks and regards,

-George

0 jameel magzal over 6 years ago in reply to George Mock

Intellectual 810 points

I cannot submit the out files

The sdk I'm using is ti-processor-sdk-rtos-c667x-evm-05.01.00.11

The utilities are in the pdk_c667x_2_0_11\packages\ti\boot\examples\ethernet\Utilities directory, however the mergebtbl is missing and i cant seem to be able to find it anywhere in the SDK, it's been 8 months since i downloaded it so i'm not sure where i got this from.

Edit: in the processors wiki page KeystoneI_Bootloader_Resources_and_FAQ , the utilities available in the SDK are listed , no mergebtbl is found, however, there is the bfmerge which seems to do the same job.

i tried using it but there is no executable file.

thanks

Jameel

0 Rahul Prabhu over 6 years ago in reply to jameel magzal

TI__Guru** 116170 points

JAmeel,

As you have noticed the mergebtbl is not part of the SDK installer. BFmerge tool was previously known as mergebtbl so I would recommend that you use that. If you are looking for the source and the binary then you need to look for it in the boot folder of Processor SDK RTOS

pdk_c6678_x_x_xx\packages\ti\boot\ibl\src\util\btoccs

If you don`t find it, I am attaching the source and the executable:

2110.boot_utilities.zip

Hope this helps.

Regards,

Rahul

0 jameel magzal over 6 years ago in reply to Rahul Prabhu

Intellectual 810 points

Thanks Rahul,
I needed that utility, looks like the boot is happening but for some reason waking up the second core is not, i have some doubts about what im doing so ill leave my questions here, please let me know if i need to open another e2e post

Currently core0 is running correctly, i am writing the boot magic number to core 1 magic address at the start of core 0 code as follows:

/* Unlock the chip registers */
DEVICE_REG32_W(KICK0, 0x83e70b13);
DEVICE_REG32_W(KICK1, 0x95a4f1e0);

DEVICE_REG32_W(BOOT_MAGIC_ADDR(1),0x0c160740);
cycleDelay(1000000);
DEVICE_REG32_W(IPCGR(1), 1);
cycleDelay(1000000);

0x0c160740 is the ENTRY POINT SYMBOL: "_c_int00" address: 0c160740 of core 1 taken from core1.map file
no sections are being loaded to DDR memory, and DDR memory is being initializes using the same process from the gel file only ported to core0 code, i connected to the cores using ccs after the boot is done and i see that core 0 is working but core 1 PC is 0x20B002C8 with no change, checked memory and looks like the boot table I sent to the dsp using Ethernet has mapped the sections correctly.

It seems like the interrupt is not waking up core 1, any idea what might cause this ?

0 Rahul Prabhu over 6 years ago in reply to jameel magzal

TI__Guru** 116170 points

Jameel,

Please take a look a the examples that we have provided here to make sure your code lines up :

processors.wiki.ti.com/.../KeystoneI_Bootloader_Resources_and_FAQ

there is an example for C6678 in the PCIE or SRIO example which you can use as reference.

Regards,
Rahul

Processors

Processors forum

CCS/TMS320C6678: Code Optimization and output sizesd