Hi,
After carefully studying sprugy5.pdf, TMS320C6678.pdf, spruea7f.pdf (as a reference to an i2c boot for a 648x) several other documents, some reverse engineering and many trial and errors on our board, we are still unable to successfully boot from i2c.
We got some tools (b2ccs.exe, b2i2c.exe, bconvert64x.exe, bin2ccs.exe, ccs2bin.exe, romparse.exe) to create the i2c boot image, but the information for the 667x is incomplete.
We create a big endian boot app (our TI is strapped to be big-endian).
cl6x -c -o1 -ms2 -mv6400+ -me --verbose --verbose_diagnostics -g -as -ss -I $CCSTOOLPATH/include reboot.c
cl6x -c -o1 -ms2 -mv6400+ -me --verbose --verbose_diagnostics -g -as -ss delay.s
cl6x -z nysh.cmd -me -l /usr/local/CCSv5/ccsv5/tools/compiler/c6000/lib/rts64pluse.lib -m reboot.map -o reboot.out
then, we run the tools to get the i2c boot image:
hex6x -a -boot -bootorg 0x400 -e _c_int00 -order M -memwidth=32 -romwidth=32 -o reboot.btbl reboot.out
./bconvert64x.exe -be reboot.btbl reboot.bc.btbl
./b2i2c.exe reboot.bc.btbl reboot.bc.btbl.i2c
./b2ccs.exe reboot.bc.btbl.i2c reboot.bc.btbl.i2c.ccs
./romparse.exe reboot.i2cmap
cp i2crom.ccs i2crom.dat
./ccs2bin.exe i2crom.ccs i2crom.bin
./ccs2bin.exe -swap i2crom.ccs i2crom.swap.bin
We were told that the i2crom.dat file is the one we should use. This is a file containing strings and looks like :
1651 1 10000 1 1b5
0x00200000
0x00280000
0x00000000
(etc...)
when we flash this file as is in the i2c eeprom, it does not work. The first level bootloader stops after reading the first 5 bytes, which would be the “1651 “ string, binary representation being 0x31 0x36 0x35 0x31 0x20.
It seemed a bit strange to us to write ASCII strings into the I2C, but it could have advantages with regard to endianess translation.
Looking at the i2c contents in a tomahawk reference board, this assumption seems ridiculous because there the i2c contents is just binary, containing boot parameter tables.
Anyway, we have
binary files ( i2crom.bin
and i2crom.swap.bin, cfr tool steps above
), but these do not yield the expected result either. The boot-image
is just not accepted by the first level boot-loader. It stops after reading a few bytes from the image.
File contents of i2crom.bin
00 00 20 00 00 00 28 00 00 00 00 00 00 01 01 00 00 (etc...)
File contents of i2crom.swap.bin begins with
00 20 00 00 00 28 00 00 00 00 00 00 00 01 01 00 00 (etc...)
so these tools strip of the first line (“1651 1 10000 1 1b5” ), and write the data in (swapped) binary format.
The romparse tool generates the image taking into account the reboot.i2cmap file:
section {
boot_mode = 40
param_index = 0
options = 1
multi_i2c_id = 0
my_i2c_id = 10
core_freq_mhz = 122
i2c_clk_freq_khz = 50
exe_file = "reboot.bc.btbl.i2c.ccs"
dev_addr_ext = 0x50
next_dev_addr = 0x50
next_dev_addr_ext = 0x51
address_delay = 100
sw_pll_prediv = 0
sw_pll_mult = 0
sw_pll_postdiv = 0
sw_pll_flags = 0
}
What is this file format? e.g. boot mode is 40 in this file, should it not be 5 (as in cfr sprugy5.pdf) ?
Is there a minimum size requirement for the I2C EEPROM?
Should there always be 64 (0x40) boot parameter table entries?
Anyway, we are missing quite some information. Is there anybody here who has experience in generating these i2c boot images (preferably for a C667x) and can point out some (obvious) errors?
Up till now, nobody is able to tell us which image - and how these images - should be flashed into the i2c.
We need to get the i2c boot working in order to be able to boot (in a third stage) from PCIe.
Best regards,
gbo.
