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.
