TI experts-
We have created a separate and independent IBL CCS project. We removed iblinit.c (keeping some functions, and setting boot table options inside main(). It was a tedious and time-consuming effort, but it builds with no errors / warnings, and creates a standard .out file and .map file. We have tested the .out file to boot an OS and it works.
The purpose of this process is to:
-allow boot into a user command-line, from which IBL boot
mode is a user-controlled option (other options include
low-level hardware functional tests required in our project)
-eliminate need for boot-table and i2cconfig.gel file
steps, v1.0 silicon PLL work-arounds, FPGA dependencies,
and other complexities of the default IBL process
To allow automated and/or user-controlled usage, here are the steps I'm using:
1) Create a .bin file from the .out file, using modified rom_parse and supporting files. There are no errors or warnings and the resulting .bin file is 53 kByte.
2) Write the .bin file to I2C EEPROM address 0x51 (using eepromwriter).
3) After power-on boot of our command-line program from I2C EEPROM address 0x50, enter a 'boot os' command to cause our program to read from I2C 0x51 and store to 0x00800000 (L2 mem starting address of code and data, according to our IBL .map file).
4) Branch to the entry-point specified in our IBL .map file.
Does this sound ok? One thing I noticed is after creating the .bin file there is an ibl_i2crom.map.pp file with contents (excerpted):
section {
param_index = 0
boot_mode = 40
sw_pll_prediv = 1
sw_pll_mult = 16
sw_pll_postdiv = 2
options = 1
core_freq_mhz = 625
i2c_clk_freq_khz = 200
dev_addr_ext = 0x51
}
I assume this info applies only in the case where I2C contents would be read by the onchip bootloader, not the method we're using. Is that correct? Is there any other "gotcha" to be aware of? Thanks.
Jeff Brower
Signalogic
PS. A reference thread for background on this question is http://e2e.ti.com/support/dsp/c6000_multi-core_dsps/f/639/p/362997/1281244.aspx#1281244
