
DESCRIPTION
-----------
This readme is a basic description of the Javascript function 
written to bootload DSP/BIOS applications, leveraging the
new table() linker operator in CGT 5.0.
It also describes how it it's used in the context of the RF3 DSK6713
example.

KEY FILES
---------
- applyTableBinitCmdFile.tci: Javascript function to append a string, 
principally ", table(BINIT)", to DSP/BIOS initialized LOAD/RUN sections
- app.pjt : project file for RF3 dsk6713. It runs a batch file as a 
post-build step, which in turn runs tconf.
- appcfg.cmd : the DSP/BIOS generated command file which gets modified 
by the Javascript function
- appcfg.tcf : the top-level Tconf script that calls the 
applyTableBinitCmdFile() function.
- readme.txt: this file

DETAILS
-------
A Javascipt function, applyTableBinitCmdFile() has been written to 
modify an application's generated DSP/BIOS *cfg.cmd file in order to
append the new table() operator for bootloading a BIOS application
  
The function works around a limitation in DSP/BIOS 5.1 or lower,
in that the configuration (gconf/tconf) does have table()
capabilities -- it only supports LOAD, RUN addresses in the *cfg.cmd file.

The fxn takes an input *cfg.cmd file and creates
a new/existing command file with table(binit) appended to sections
that have different load/run addresses i.e.

Before the Javascript function call
   .bios:    {} load > FLASHREST, run > IRAM
   
After the Javascript function call
   .bios:    {} load > FLASHREST, run > IRAM, table(BINIT)

Normally in Reference Frameworks, we use a makeConfig.bat to build
the DSP/BIOS configuration separately, to avoid running
tconf on every build. However, in this case we need the 
*cfg.cmd file to be post-processed -- without this, a "Rebuild All"
would run gconfgen and produce a *cfg.cmd without the table(binit)
additions. Hence, we insert a post-build step to the build of
app.cdb to run tconf every time. Hence, after gconfgen runs,
tconf will run, thus ensuring the post-processing table()
additions get appended to Load/Run sections.


Note that the command to run the hex6x tool is *not* built in
as a post-build step, since the user may not want to re-run &
Flash on every rebuild.

You may also notice the following lines in Dsk6713_mem.tci...

// do placement of e.g. .text, .cinit, .bss etc in link.cmd
tibios.MEM.USERCOMMANDFILE = true;

...this is simply to force the user to peek at the table(BINIT)
syntax via specification in the user's link.cmd -- it makes the 'magic'
underneath *cfg.cmd a little more understandable!

