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.

TMS320C6670: Making bootable binary for C6670

Part Number: TMS320C6670


Hello!

In our system we have C6670 connected to Linux host PC via Ethernet. We use Ethernet boot process.

For long time we established a process, when we use hex utility to produce boot table and then convert into binary suitable for boot. Looking inside mcsdk_2_01_02_06\tools\boot_loader\examples\ethernet\Utilities\bconvert64x.c and mcsdk_2_01_02_06\tools\boot_loader\examples\ethernet\Utilities\bootpacket.c I found I could do that kind of conversions myself. First of all, we made simple utility, which converts ASCII hex file to binary. I suspect, fancy functionality of bconvert64x.c was provided to deal with different memory organizations and probably endianness conversion. We don't need that, as our device is 32 bit, all the data 32 bit, and we always work in default little endian mode. Thus my utility consists of merely converting hex notations to their binary representation one by one until file end. We also don't use bootpacket.c, as we developed our own solution to reset DSP, capture its Eth ready frame, pickup its MAC address and compose and transmit frames with boot table fragments. That works perfectly for us.

What I don't like in process, that we were using batch file to invoke hex utility of TI and then our inhouse utility. From machine to machine version of GCT could be different, and automation of finding right CGT in batch was a job I wish to escape. Meanwhile I saw in the forum there is a way to produce binary as postbuild step at http://processors.wiki.ti.com/index.php/Projects_and_Build_Handbook_for_CCS#Pre_and_Post_Build_Steps  as "${CCS_INSTALL_ROOT}/utils/tiobj2bin/tiobj2bin" "${BuildArtifactFileName}" "${BuildArtifactFileBaseName}.bin" "${CG_TOOL_ROOT}/bin/ofd2000" "${CG_TOOL_ROOT}/bin/hex2000" "${CCS_INSTALL_ROOT}/utils/tiobj2bin/mkhex4bin". Surely

dsp.out
-a
-boot
-e _c_int00
-order L

ROMS
{
   ROM1:  org = 0x0400, length = 0x8000000, memwidth = 32, romwidth = 32
          files = { dsp.btbl }
          
}       

With this step I am receiving boot table starting with

 // that is binary 02 symbol
$A0400,
0C 08 D0 40 00 00 44 60 0C 0B 18 28 04 53 53 01 07 53 38 00 00 00 3F 00 

Interesting point, that first two lines are just skipped by bconvert64 utility. Secondly, I have clue about $A0400 significance, but it matches --bootorg parameter. I skimmed trough Assembly Lang User Guide and Bootloader UG, but did not develop my understanding,

Question 2. Whether hex utility could provide output in binary form?

Question 3. What is significance of those 2 lines in boot table, produced by hex utility?

Thank you.

  • Hello. In hex utility there's an undocumented option -b (generates binary image). For me it works better than all this zoo of utilities..

  • Hello Sergey,

    Thank you for your suggestion, I never knew about that feature.

    I've tried myself and it does produce binary. However, DWORD ordering is different:

    Original working:
        0000000000: 0C 08 D0 60 00 00 45 B0
    -b option
        0000000000: 60 D0 08 0C B0 45 00 00

    I've tried to play with L/M option, they have no effect. For Ethernet boot I need that file in BE ordering. Don't you know another undocumented switch to do that?

    Thanks in advance.

  • rrlagic said:

    I've tried to play with L/M option, they have no effect.

    I guess that is why this option is undocumented.

    I think, you can try to enable hex utility in project properties:

    It will generate desired output in "project folder/Debug" and then run self-made utility as postbuild step to reverse byte order.

  • Thanks, that exactly what I observed and what I am doing now.
    As you mentioned in the first comment, the bunch of utilities suggested to use is like a real zoo. I can guess they could be needed to handle some specific targets. For me, when I skimmed through utilities source code I found the only step I really need is to dump hex to binary, or, as you suggest, repack binary BE order.
    It seems no other way is possible, though I still wish someone from TI come and confirm.
    Thanks again.