C6657 EVM SPI Boot Problem

George,

Please take a look at the e2e post. There is a typo in the bootloader user guide. Refer to the tiboot.h for the correct boot parameter structure format.

http://e2e.ti.com/support/dsp/c6000_multi-core_dsps/f/639/p/165943/773551.aspx#773551

THanks,

Arun.

Arun,

Thank you for the clarification that the bootloader user guide (SPRUGY5B) has erroneous information regarding the SPI Boot Parameter Table (Table 3-27).  I would say that the information provided in the user guide document is a bit more than a *typo*, but rather completely wrong; or at a minimum a gaggle of typos.  A typo I'd say would be something like the description to the Bus Freq, KHz entry at byte offset 32 wherein it states "The kHz portion of the SPI buf frequency. Defaut = 0".  Here there's a true typo of "buf" instead of the intended word "bus".

I was able to download the tiboot.h and other RBL code for the 6670 and 6678.  I am assuming the C6657's RBL is similar/same as to what you have provided.  Is that correct?  Assuming so, the SPI Boot Parameter Table is much clearer now (thanks), but at the sametime still misleading.  I needed to dig a fair bit to determine the following...

1)  The code suggests that the boot_mode is 50 for SPI boot and not 6 per the documentation of Boot Parameter Common Values (Table 2-6).  Another "typo" I'm guessing.

2)  The addrWidth needed to be set with the actual value of 16 or 24 and not the 0 or 1.

3) The presense of the macro BOOT_PARAMS_SPI_SET_BOOTTBL_MODE() seemed to suggest that the "mode" setting needed to be convolved within the "options" field, but if it is used to convolve in the "mode" setting after setting the "options" it would obliterate the "options" data.  In the end I decided to eliminate using this macro.

There are many other gems that I'm finding.  At the moment I'm struggling with the next issue and that is an apparent infinite SPI read loop that the RBL embarks on following the loading of the following SPI Boot Parameter Table which does apparently load successfully as far as I can tell.

0x00280000 0x00320000 0x40200002 0x00010018 0x00000000 0x00020001 0x03e80005 0x00000000 0x00280000 0x00000000

I witness the RBL perform an SPI read (03 00 00 28) following the loading and interpretation of the above SPI Parameter Table.  This is the correct read_addr to load the Boot Table below which is immediately following the parameter table.  I witness the correct data is being read, i.e. 0x00810000.  At least my o-scope shows that is what is being read and since the RBL seems to be interpreting the parameter table correctly (getting 0x00000028) I can trust that this first 4-byte read of the Boot Table is correct also.

Here's the Boot Table data at offset address 0x00000028 within the NOR Flash.

0x00810000 0x00000040 0x00810000 0x0099a228 0x00889168 0x010100a8 0x010040e8 0x01080226 0x01810828 0x018040e8 0x018c3626 0x020c0226 0x0001a120 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000004 0x00810100 0x1234abcd 0x00000001 0x00810201 0x12000000 0x00000002 0x00810210 0x12340000 0x00000000

There seems to be an issue in that the RBL goes into an infinite loop performing the same back-to-back SPI read (03 00 00 28) getting the same 0x00810000 data over and over.

I've deciphered the RBL code pointed to by you and found that spimain.c's bootMainSpi() contains a while loop which will never exit if sizeBytes returned from boot_spi_read_block() is zero.  Apparently that's what's happening.  It appears that I've been again misled as to the contents of a Boot Table as expected by the RBL.  The boot_spi_read_block() function seems to suggest that it expects the first 4 bytes read to be a "size" record, which is being violated by the magnitude of the 0x00810000 data value it is reading.

Here's my confusion.  The documentation in the infamous SPRUGY5B states fairly clearly in section "2.5.3 Boot Table" that the Boot Table consist of the following

• 32-bit header record indicating where the bootloader should branch after it has completed copying the data.
• For each COFF section

• 32-bt Section byte count
• 32-bit Section address (destination address for the copy)
• The data to be copied

• A 32-bit Termination record (0x00000000)

As you can see my Boot Table provided above clearly follows this specification, but that's obviously not the magic syntax that the C6657's RBL is expecting.

At this point I'm pretty tired of guessing and deciphering the RBL code as to what it's expecting for the Boot Table syntax.  I would appreciate TI's help in definitively documenting what is needing to be provided.

Where can I get the updated Keystone Bootloader User Guide?  If it's not available, when will it be available?

This poor documentation has cost me literally weeks of time and at the moment I can't trust anything I've been reading in this user guide or related TI documentations.

If this "simple" task of SPI booting the C6657 is any indication of what I can expect going forward with this device, I can only imagine the mysteries that await me in getting PCIe_RC to work.

-George

Arun,

Thank you for the clarification that the bootloader user guide (SPRUGY5B) has erroneous information regarding the SPI Boot Parameter Table (Table 3-27).  I would say that the information provided in the user guide document is a bit more than a *typo*, but rather completely wrong; or at a minimum a gaggle of typos.  A typo I'd say would be something like the description to the Bus Freq, KHz entry at byte offset 32 wherein it states "The kHz portion of the SPI buf frequency. Defaut = 0".  Here there's a true typo of "buf" instead of the intended word "bus".

<Arun> The structure in the bootloader UG is based on the old spec. Seems like lot changed.

I was able to download the tiboot.h and other RBL code for the 6670 and 6678.  I am assuming the C6657's RBL is similar/same as to what you have provided.  Is that correct?  Assuming so, the SPI Boot Parameter Table is much clearer now (thanks), but at the sametime still misleading.  I needed to dig a fair bit to determine the following...

<Arun> Yes it should be same.

1)  The code suggests that the boot_mode is 50 for SPI boot and not 6 per the documentation of Boot Parameter Common Values (Table 2-6).  Another "typo" I'm guessing.

<AVM> This is internnal value. You will still setup as 6 in the bootstrap pins. But if you are updating through the boot parameter value you need to use the value in table 3-20.

2)  The addrWidth needed to be set with the actual value of 16 or 24 and not the 0 or 1.

<Arun> Again it is the internal selection done by RBL.

3) The presense of the macro BOOT_PARAMS_SPI_SET_BOOTTBL_MODE() seemed to suggest that the "mode" setting needed to be convolved within the "options" field, but if it is used to convolve in the "mode" setting after setting the "options" it would obliterate the "options" data.  In the end I decided to eliminate using this macro.

There are many other gems that I'm finding.  At the moment I'm struggling with the next issue and that is an apparent infinite SPI read loop that the RBL embarks on following the loading of the following SPI Boot Parameter Table which does apparently load successfully as far as I can tell.

0x00280000 0x00320000 0x40200002 0x00010018 0x00000000 0x00020001 0x03e80005 0x00000000 0x00280000 0x00000000

I witness the RBL perform an SPI read (03 00 00 28) following the loading and interpretation of the above SPI Parameter Table.  This is the correct read_addr to load the Boot Table below which is immediately following the parameter table.  I witness the correct data is being read, i.e. 0x00810000.  At least my o-scope shows that is what is being read and since the RBL seems to be interpreting the parameter table correctly (getting 0x00000028) I can trust that this first 4-byte read of the Boot Table is correct also.

Here's the Boot Table data at offset address 0x00000028 within the NOR Flash.

0x00810000 0x00000040 0x00810000 0x0099a228 0x00889168 0x010100a8 0x010040e8 0x01080226 0x01810828 0x018040e8 0x018c3626 0x020c0226 0x0001a120 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000004 0x00810100 0x1234abcd 0x00000001 0x00810201 0x12000000 0x00000002 0x00810210 0x12340000 0x00000000

There seems to be an issue in that the RBL goes into an infinite loop performing the same back-to-back SPI read (03 00 00 28) getting the same 0x00810000 data over and over.

I've deciphered the RBL code pointed to by you and found that spimain.c's bootMainSpi() contains a while loop which will never exit if sizeBytes returned from boot_spi_read_block() is zero.  Apparently that's what's happening.  It appears that I've been again misled as to the contents of a Boot Table as expected by the RBL.  The boot_spi_read_block() function seems to suggest that it expects the first 4 bytes read to be a "size" record, which is being violated by the magnitude of the 0x00810000 data value it is reading.

Here's my confusion.  The documentation in the infamous SPRUGY5B states fairly clearly in section "2.5.3 Boot Table" that the Boot Table consist of the following

• 32-bit header record indicating where the bootloader should branch after it has completed copying the data.
• For each COFF section

• 32-bt Section byte count
• 32-bit Section address (destination address for the copy)
• The data to be copied

• A 32-bit Termination record (0x00000000)

As you can see my Boot Table provided above clearly follows this specification, but that's obviously not the magic syntax that the C6657's RBL is expecting.

<Arun> George, I was told that you got a sample code from the FAE. Did you use all the utilities in that example? I suspeect that the boot table is correct, but the bytes are out of order.

At this point I'm pretty tired of guessing and deciphering the RBL code as to what it's expecting for the Boot Table syntax.  I would appreciate TI's help in definitively documenting what is needing to be provided.

Where can I get the updated Keystone Bootloader User Guide?  If it's not available, when will it be available?

This poor documentation has cost me literally weeks of time and at the moment I can't trust anything I've been reading in this user guide or related TI documentations.

If this "simple" task of SPI booting the C6657 is any indication of what I can expect going forward with this device, I can only imagine the mysteries that await me in getting PCIe_RC to work.

-George

Arun,

Thanks for feedback.

I agree with you that the SPRUGY5B documentation does *not* represent the current RBL SPI Boot implementation within the C6657 whatsoever.

Again, when will the improved bootloader documentation become available?

Per my question 3) earlier in regards to the presence of the macro BOOT_PARAMS_SPI_SET_BOOTTBL_MODE() , is the RBL's SPI Boot logic expecting the combining of the "mode" within the "options" field?  At the moment I am not doing this.

After coming to the realization of this bad documentation and re-visiting my usage of the TI provided tools to generate the ulitimate file "spirom_le.swap.bin" being programmed into the EVM C6657's NOR flash using norwriter, I found that I had abandoned the usage of the "b2i2c" utility which was the missing link that is generating the magic 32-bit data value being expected by the RBL SPI boot at the start of loading the Boot Table.  At the time I rationalized that this "b2i2c" was solely for i2c and not SPI.

Obviously, the existing documentation regarding the format of the Boot Table and associated format of data as expected by the CC657's RBL SPI boot logic is incorrect.  This is what caused me to eliminate the "b2i2c" utility which at the time was injecting an observedly bogus 32-bit data value at the start of the Boot Table.  Well in hindsight and after understanding that this is the issue causing the RBL SPI boot logic to reject the Boot Table, I realized that the "b2i2c" was indeed needed for SPI.

So, I've added the "b2i2c" utility back in and now the magic 32-bit data value is being inserted at the start of the Boot Table.  As a result the RBL SPI boot logic is progressing to load the entire Boot Table successful.  The infinite SPI Read loop happening earlier is gone and I have the expected behavior of seeing SPI reads of the entire Boot Table.

I'm inferring from "spimain.c" that the "magic 32-bit" data at the start of the Boot Table appears to be the checksum.  Correct?  I've disabled checksum via parameter table, but it appears that the RBL ignores it regardless.  Correct?

With that said, I'm using my home-brewed version of "romparse" called "bootbuild" which I had created earlier as the usage of "romparse" was not generating the expected output behavior per the eroneous SPRUGY5B documentation Table 3-27.

Here's the contents of "mySpiBoot.bat" ...

hex6x mySpiBoot.rmd

bconvert64x -le mySpiBoot.btbl mySpiBoot.btbl.bcv64x

b2i2c mySpiBoot.btbl.bcv64x mySpiBoot.btbl.bcv64x.i2c

b2ccs mySpiBoot.btbl.bcv64x.i2c mySpiBoot.btbl.bcv64x.i2c.ccs

bootbuild mySpiBoot.map

ccs2bin -swap i2crom.ccs spirom_le.swap.bin

Here's the contents of "mySpiBoot.rmd" being used...

mySpiBoot.out -a -boot -e _c_int00

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

For completeness, "mySpiBoot.out" is actually renamed from the "simple.out" provided from TI.

Here's the "mySpiBoot.map" being used...

section { boot_mode = 50  param_index = 0  options = 1  core_freq_mhz = 1000  exe_file = "mySpiBoot.btbl.bcv64x.i2c.ccs"  next_dev_addr_ext = 0x0  sw_pll_prediv = 5  sw_pll_mult = 32  sw_pll_postdiv = 2  sw_pll_flags = 1  addr_width = 24  n_pins = 4  csel = 0  mode = 0  c2t_delay = 0  bus_freq_mhz = 0  bus_freq_khz = 500 }

My BOOTBUILD (replacement for romparse) usage generates SPI Boot Parameter Table ...

0x00280000 0x00320000 0x45200002 0x00010018 0x00040000 0x00000000 0x03e80000 0x01f40000 0x00280000 0x00000000

As you can see my "bootbuild" utility generates the correct read_addr 0x00000028 and the RBL performs the SPI read (03 00 00 28) and gets the correct data where the Boot Table resides at byte offset 40.

The Boot Table immediately follows at byte offset 40

0x00803af5 0x00810000 0x00000040 0x00810000 0x0099a228 0x00889168 0x010100a8 0x010040e8 0x01080226 0x01810828 0x018040e8 0x018c3626 0x020c0226 0x0001a120 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000004 0x00810100 0x1234abcd 0x00000001 0x00810201 0x12000000 0x00000002 0x00810210 0x12340000 0x00000000

Alternatively, if I use ROMPARSE in place of BOOTBUILD it generates a BAD read_addr as follows ...

Here's the SPI Boot Parameter Table generated using the "romparse" utility with the above "mySpiBoot.map" file.

0x00500000 0x00320000 0x40200002 0x00010018 0x00040000 0x00000000 0x03e80000 0x01f40050 0x04000000 0x00000000 0x00000000 0x00000000

0x00000000's up until byte offset 1024

This fails at SPI boot time by the RBL performing an infinite SPI read (03 50 04 00) and continually getting the value FF FF FF FF which is un-written Flash.  The read_addr being generated by "romparse" is wrong in that it is reading too far into the NOR Flash, i.e. 5 MB.  I would expect the read_addr should be 0x000400, i.e. 1024 bytes as this is where the Boot Table resides as shown below.

In this case the Boot Table is at byte offset 1024 as follows...

0x00803af5 0x00810000 0x00000040 0x00810000 0x0099a228 0x00889168 0x010100a8 0x010040e8 0x01080226 0x01810828 0x018040e8 0x018c3626 0x020c0226 0x0001a120 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000004 0x00810100 0x1234abcd 0x00000001 0x00810201 0x12000000 0x00000002 0x00810210 0x12340000 0x00000000

Why is the "romparse" utility generating the incorrect read_addr of 0x500400 ?

Does the "romparse" utility need to be recompiled for SPI usage?  For that matter are rebuilds necessary for any of the other utilities for SPI usage?

As an observation, I'm not pleased with the "romparse" insertion of ~1024 bytes of zeroes between the SPI Boot Parameter Table and the actual Boot Table.  As you can see my "bootbuild" replacement appends the Boot Table immediately following the parameter table.  This is not a big deal, but seems a bit wasteful if only one parameter table is present.

Additionally, I was wondering about the maximum SPI clock rate that the RBL can read and load the Boot Table.

The reason why I'm asking is that I came across the following within the file "nysh.h" within the "SPI boot mode" section on line 565.

#define chipDefaultSpiBusFreqMhz()          0      /* 2 MHz max */

#define chipDefaultSpiBusFreqKhz()          500

We are hoping that the RBL's SPI can clock data on the order of 50 MHz or higher.

What is the C6657 RBL's maximum SPI clock rate for reads?

-George

4520.ddrcfg.s

1447.simple.s

Arun,

I wanted to post some feedback of my latest SPI Boot attempts on EVM C6657.

I still haven't been able to use the "romparse" utility due to the read_addr issue.  I'm still using my replacement utility "bootbuild" to perform this step.

Any insight into why romparse isn't generating the correct read_addr?

After further investigation I've determined that the utility "b2i2c" is chunking the Boot Table up into blocks of 128 bytes and inserting a 32-bit value representing the Block_length (MSB 16-bits) | 1s_comp_checksum (LSB 16-bits) for the block that follows.  I've deduced this from "spimain.c" in the path c:\ti\_Downloads\C6678_pg10_bootloader\Shannon\main\spimain.c

Is there better documentation or white-paper on the entire build process for SPI Boot and the format of the data that is expected?

Using the aforementioned build steps within mySpiBoot.bat, mySpiBoot.rmd, but with the following changes to mySpiBoot.map I was able to get faster Boot Table loading.

section {  boot_mode = 50  param_index = 0  options = 1  core_freq_mhz = 1000  next_dev_addr_ext = 0x0  sw_pll_flags = 1  sw_pll_mult = 19  sw_pll_prediv = 0  sw_pll_postdiv = 2  addr_width = 24  n_pins = 4  csel = 0  mode = 2  c2t_delay = 0  bus_freq_mhz = 50  bus_freq_khz = 0  exe_file = "mySpiBoot.btbl.bcv64x.i2c.ccs" }

The SPI Boot Parameter Table ...

0x00280000 0x00320000 0x40130002 0x00010018 0x00040000 0x00020000 0x03e80032 0x00000000 0x00280000 0x00000000

The Boot Table immediately follows at byte offset 40

0x00803af5 0x00810000 0x00000040 0x00810000 0x0099a228 0x00889168 0x010100a8 0x010040e8 0x01080226 0x01810828 0x018040e8 0x018c3626 0x020c0226 0x0001a120 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000004 0x00810100 0x1234abcd 0x00000001 0x00810201 0x12000000 0x00000002 0x00810210 0x12340000 0x00000000

As you can see I've changed the PLL settings to achieve the desired 1000 Mhz present on the EVM C6657, as well I've increased the bus_freq_mhz = 50.  This causes the RBL to increase the SPI clock frequency at the start of loading the Boot Table which is what I was hoping to witness.  The bit clock interval is ~18 ns which is ~55 Mhz.  I've verified that the code/data is being loaded into L2 SRAM correctly using CCS.

I was expecting the SPI bit clock interval to be ~20 ns for the 50 Mhz bus frequency specified.  I'm guessing my PLL setup is incorrect.  But how?

The calculation I'm using with the assumption of a 100 Mhz input CLKIN to PLL is as follows.  The formula is obtained from SPRS814A TMS320C6655/57 Device Overview Section 2.5.3.

CLK = CLKIN × (PLLM+1) ÷ (OUTPUT_DIVIDE × (PLLD+1))

CLK = (100 * (19+1)) / (2 * (0+1))  ==> 2000 / 2 ==> 1000

Is this correct?  What should be the correct PLL setup on the EVM C6657 to run at 1000 Mhz?  Something is not quite right here., but what?

The next observation is that I'm witnessing a byte to byte interval of ~560 ns.  This is the time that the RBL is transacting the byte previously read and storing it into destination memory.  I've informed the RBL via the parameter table to disable checksum, so I'm assuming no time is being wasted on verifying the checksum.  Correct?

Here the destination for the code/data being loaded is internal L2 SDRAM which is fast.  I'm assuming that this interval would be longer if the destination memory were DDR.  This is a data transfer rate of 1,785,714 bytes/sec or ~1.7 MB/s.

How much slower will it be to DDR?

This isn't horrible, but I wondering if this is an expected data transfer rate with the settings and target memory I have.

Is it possible to improve this SPI Boot Table data transfer rate?  We were expecting it to be much much faster.

The next step I've embarked upon is to have the RBL to perform the DDR Configuration setup during the Boot Table load.  I'm under the impression that this is possible per the documentation provided in SPRUGY5B at the bottom of page 2-3 and to of page 2.4

The bootloader also has a DDR configuration table that, by default, is initialized

to all zeros. During the bootloader process, the parameter table is polled after

every boot table section is complete. The DDR3 is configured if the bootloader

finds that the enable bitmap field is non-zero. This allows a single boot table to

configure the DDR table, then load data to DDR. The DDR configuration boot

parameter table is shown in Table 2-3.

I know that it is risky to rely on this erroneous document SPRUGY5B, but was hoping it to be accurate in this regard.  Is it?

Furthermore, I've endeavored to populate this DDR Configuration as specified within SPRUGY5B Table 2-3 and the associated/corresponding DDR configuration definitions as found within the document SPRUGV8C "KeyStone Architecture DDR3 Memory Controller User Guide".

For the settings to use in configuring the DDR configuration I'm using the initialization code found within the function DDR3Init() within the file evmc6657.c in the following path...

C:\ti\pdk_C6657_1_1_0_3\packages\ti\platform\evmc6657l\platform_lib\src\evmc6657.c

I've created an assembly file ddrcfg.s which contains the derived DDR config table.

I have know way of verifying this is accurate, so please if there is a better set of values that I should be using I would appreciate knowing that too.

My application "mySpiBoot.out" (simple.s and ddrcfg.s) attempts to add the DDR Configuration table and have it loaded into the RBL Table memory region specified at byte offset 0x740 within CorePac0 Memory per Table 2-2.  On the C6657 this offset to the internal L2 SDRAM address is 0x00873500.  I have updated my application linker command file "simple.cmd" to locate this table at the required RBL table address of 0x00873500.

Here's the resulting SPI Boot Parameter Table...

0x00280000 0x00320000 0x40130002 0x00010018 0x00040000 0x00020000 0x03e80032 0x00000000 0x00280000 0x00000000

Immediately following at byte offset 40 is the new Boot Table which has the "b2i2c" checksum blocking depicted in bold/underline.  Note that the destination addresses are no longer internal L2 SDRAM, but rather DDR memory 0x80000000.  I've split this Boot Table appart to show the various sections that are processed by the RBL.

0x0080fb76

0x80010000 0x00000040 0x80010000 0x0099a228 0x00889168 0x010100a8 0x014000e8 0x01080226 0x01810828 0x01c000e8 0x018c3626 0x020c0226 0x0001a120 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000

0x00000004 0x80010100 0x1234abcd

0x00000001 0x80010201 0x12000000

0x00000002 0x80010210 0x12340000

0x00000068 0x00873500 0x0001417b 0x006c15be 0x00001302 0x62477ab2 0xc0ffee00 0x0000144f 0x1333780c 0x30717fe3 0x559f86af 0x5a5a5a5a 0x00000000 0x23232323 0x11111111 0x22222222 0x33333333 0x44444444 0x70074c1f 0x66666666 0x0010010f 0x88888888 0x99999999 0xaaaaaaaa 0xbbbbbbbb 0xcccccccc 0xdddddddd 0xeeeeeeee 0xffffffff

0x00000000

The problem with this Boot Table is that the load ordering of the application code/data (destined to DDR) versus the RBL's DDR Configuration table load is NOT correct.  The 104 byte RBL DDR Configuration table is the LAST section within the Boot Table.  This is a problem as it will not be interpreted by the RBL and configure DDR memory prior to loading sections into that DDR memory as is the intent of this build.

The linker for some reason is always placing the .text/.data sections prior to the .ddrcfg section.  I've attempted to have the linker rearrange this ordering to get the .ddrcfg data table to occur prior to the application code/data, but haven't been successful.

Do you know a way that I can direct the linker (or other tool) to arrange these sections such that the required DDR Configuration table becomes the first section within the Boot Table.  I know that I could manually fix this ordering in the process by rearranging the sections prior to "b2i2c" running, but that would be clunky.  There should be a way to accomplish this using the linker, but how?

I tried to individually attach files, but many were blocked, so I created a zip with all the files you'll need to re-create this build in hopes that you'll be able to show me how to re-order the Boot Table sections to prep DDR prior to using it.

Additionally, the DDR Configuration entries that are being disabled have "bogus" pattern data present for ease of locating within SPI traffic on the o-scope.  This I'm assuming should be OK as the "Enable bitmap" per Table 2-3 is disabling these un-intended entries from being used.

I look forward to your feedback.

-George

Arun,

Here's missing zip file.

4848.mySpiBoot_201212041639.zip

George,

SOrry for the dealy. I am looking at your comments as we speak. I am trying to get a wiki page to put all the relevant information. But I am swamped with other issues. But I will definitely share with you. I will reply to your other question ASAP.

Thanks for your feedback. We understand it is not perfect. unfortunately there are a lot of moving parts between the two different devices than we expected. Hopefully based on your feedback we can improve it far better that it is now.

Thanks,

Arun.

Arun,

I look forward to your wiki page on this issue.

Any information/clarification on this issue here would be welcomed also.

Here's some additional information that I've found that may be helpful as well.

I'm quickly concluding that the information present in SPRUGY5B regarding the RBL CorePac0 Memory Table 2-2 isn't correct.  The observation I've made following an SPI Boot using the parameter table and boot table provided earlier is that the SPI Boot Parameter Table is *not* going to the expected location within CorePac0 memory, i.e. 0x08C0 offset wthin the top 0xD23F bytes of CorePac0's L2 SDRAM.  I was expecting it to be found at address 0x10900000 - 0xD240 + 0x08C0 ==> 0x108F3680, but rather I'm finding it at location 0x108FFF00.  I'm inspecting CorePac0's L2 SDRAM by connecting to the EVM using CCS/JTAG following an SPI Boot.

This leads me to conclude that at a minimum the Table 2-2 is incorrect and that the DDR Configuration table may not be located at byte offset 0x0740 within the top 0xD23F bytes of CorePac0's L2 SDRAM.

I've identified several "zeroed" out regions near the location where the SPI Boot Parameter table is landing and have attempted to target my Boot Table's DDR Configuration table section into these areas and have not yet definitively verified the correct region.  I see that the DDR Configuration table is landing where I'm directing it to go, but the RBL is not enabling DDR memory as a result.  I'm verifying this via CCS/JTAG connection and checking DDR memory at address 0x80000000 with a pattern which doesn't stick.  Either the DDR Configuration table I'm loading is incorrect (a real possibility) or I'm directing it to be loaded to an incorrect location still.

I've inspected the RBL code you provided earlier, but haven't been successful in determining the RBL's CorePac0 Memory layout and in particular where it expects to find the DDR Configuration Table 2-3.

Additionally, I'm not sure if the DDR Configuration Table 2-3 as documented is correct either.

-George

HI George,

The problem with the DDR configuration is that we were hoping to have the same configuration across all KeyStone devices. But apprently that is not the case. The DDR configuration you see it is for C667x. For the DDR configuration for CC665x, please use the attached document.

Thanks,

Arun.0246.DRR_Configuration_for_C6657.docx

Arun,

Thanks for the doc on on C6657 RBL DDR Configuration table.

I still have questions as things aren't working for me even with this new table layout.

First are these table offsets typos?  I think so?

DDR3_Config1 should be at offset 116

DDR3_Config57 should be at offset 340, DDR3_Config58 offset 344, DDR3_Config59 offset 348, DDR3_Config60 offset 352

I think the size of this table should be 0x164 and not 0x120 as stated in your document.

Just to be clear are we supposed to be targeting the RBL DDR Configuration to be loaded into the L2 address space of 0x008F_FD20 or CorePac0' L2 memory of 0x108F_FD20.  Are they are the same?

Does the RBL completely adhere to the "enable" bitmaps when applying the DDR Configuration table?  If not, that would mean we'd have to make sure that all entries contain valid default settings.  I'm expecting that the disabled fields are going to be ignored by RBL and C6657 reset defaults will be used.

I've been trying to populate this DDR Configuration Table using the settings from the "evmc6657l.gel" file that I'm using to successfully perform the norwriter step in updating the NOR Flash for SPI Boot testing.  This GEL file is apparently correct as I can successfully load my "app.bin" into DDR3 on EVM C6657 board during programming.  I can also interactively test DDR3 memory at 0x80000000 using CCS/JTAG and this GEL setup.  Here's the path to the GEL file I'm referring to.

C:\ti\ccsv5\ccs_base\emulation\boards\evmc6657l\gel

5661.evmc6657l.gel

After extracting the DDR3 Configuration settings from the GEL and updating the DDR Configuration table per your updated documentation it still doesn't afford the DDR3 memory to be enabled and operational following an SPI Boot.  Actually the below will not let me CCS/JTAG connect if I set the EnableBitmap bit for "PhyCtrl1"

(The entries in italics/green are the "b2i2c" checksum at start of each encoded boot table block)

SPI Parameter Boot Table...

0x00280000 0x00320000 0x40130000 0x00010018 0x00040000 0x00020000 0x03e80032 0x00000000 0x00280000 0x00000000

0x00803054

Boot Table (application code/data desitined to internal L2 SDRAM)

0x00810000

0x00000040 0x00810000 0x0099a228 0x00889168 0x010100a8 0x010040e8 0x01080226 0x01810828 0x018040e8 0x018c3626 0x020c0226 0x0001a120 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000

0x00000004 0x00810100 0x1234abcd

0x00000001 0x00810201 0x12000000

0x00000002 0x00810210 0x12340000

Boot Table section (DDR Configuration Table being targeted to 0x008FFD20)

0x00000164 0x008ffd20 0x0001417b 0x00805399 0x00ffdffd 0x00000000 0x00270002 0x62477ab2 0x00000000 0x0000144f 0x1333780c 0x30717fe3 0x559f86af 0x00000000 0x00000000 0x00000000 0x00010000 0x00000000 0x00000000 0x00000000 0x70074c1f 0x00000000 0x0010010f 0x0010010a 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000305 0x0020000f 0x00000000 0x00000000 0x00000000 0x0080793c 0x00000000 0x00000000 0x00000033 0x0000003a 0x0000002c 0x0000002c 0x00000021 0x00000000 0x80000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x000000b7 0x000000b1 0x000000a4 0x000000a4 0x00000098 0x00000200 0x00000015 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x0070ff8f 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000

When I attempt to connect to EVM C6657 via CCS/JTAG I get the failure message of "core hung".  Why?

I have a question regarding the PLL setup that I'm using and the wording of the PLL Config Ctl settings, i.e. what does each of the options mean?  I'm using "PLL is not configured" 0b00 for both parameter table PLL setting as well as DDR3 PLL setting.  Does this mean that the PLL is *not* previously configured and the PLL settings provided will be used to configure the PLL?  Or, does this mean that the PLL "will" not be configured with the provided settings?  I have the same question for 0b10 "PLL is configured".  Does this mean that the RBL will use the provided settings to configure the PLL's or does it refer to that the PLL is already configured and the provided settings will be ignored?  This terminology is quite confusing.

Again, I've tried to meticulously apply the settings from the GEL into my .ddrcfg data section which can be seen above.  I would appreciate if you could tell me what setting is preventing me from CCS/JTAG connection following reboot.  Any ideas?

Are there registers having procedural bit sequencing needing to be adhered to?  If so, I'm expecting the RBL code to perform this behavior as this couldn't be possible by our providing the DDR Configuration table via SPI.

Have you released the C6657 RBL code on the Wiki similar to the C6670/C6678?

Additionally, I still need a means to re-arrange the Boot Table above to have the DDR Configuration Table "section" being targeted at 0x008FFD20 to occur before sections needing to be targeted to DDR3 memory.  The goal is to target the application code/data to DDR3 instead of internal L2 SDRAM which is the case at the moment above.

Is there a way to have the Linker arrange the .ddrcfg section to be first?

I would appreciate your wiki SPI Boot example include a setup of DDR Configuration table via the Boot Table section mechanism and target using the EVM C6657 as I'm using here.  Please have app to be loaded target DDR3 memory and not internal L2 SDRAM.

-George

Arun,

I wanted to clarify that I can *not* connect via CCS/JTAG when field EnableBitmapMSW is set to a non-zero value.  I thought I was able to connect following an SPI Boot if PhyCtrl1 enable-bit is cleared, but further testing shows that it still fails when this field is disabled and other bits are enabled.  Attempting to connect using CCS/JTAG following an SPI Boot with above tables gives the below popup dialog message.  I'm using the XDS100v1 emulator and the EVM C6657.

Error connecting to the target: (Error -1143 @ 0x0) Device core was hung. The debugger has forced the device to a ready state and recovered debug control, but your application's state is now corrupt. You should have limited access to memory and registers, but you may need to reset the device to debug further. (Emulation package 5.0.857.0)

Any ideas as to why this might be happening?

Do you have a valid RBL DDR Configuration Table setup that I could use for SPI Boot on the EVM C6657?  That would be most helpful.

-George

Arun,

I've been further reviewing the "evmc6657l.gel" and "evmc6657.c" to correlate these two sources to understand the DDR3 configuration taking place.

Both these perform virtually the same steps using the same register value initializations, except for the value written to DATA8_WRLVL_INIT_RATIO, i.e. DDR3_Config10.  The GEL script writes a value of 0x21 whereas the .C file uses a value of 0x1C.  I'm assuming that this is not a big difference and more than likely not what is causing my SPI Boot and subsquent CCS connect issue.  Indeed using either results in the same CCS connect failure.  Which value should be used?

Some of the bit "toggling" taking place in these 2 references are not possible to be accomplished simply by our writing to the RBL DDR Configuration Table at address 0x008F_FD20 via the Boot Table.  I am assuming that these procedural steps are the responsibility of the RBL execution of transacting the DDR Configuration Table that we load into 0x008F_FD20.  Correct?

The "toggling" I'm referring to is the PHY reset bit 15 0->1->0 in DDR_PHY_CTRL_1.  Is this being accomplished by the RBL code?  I am assuming this is being done by the RBL.  Correct?

Is it possible to SPI Boot application code directly into DDR3 memory by solely loading a Boot Table and not implementing an IBL (intermediate boot load) approach?  Or do we need to perform a Boot Config and re-enter RBL to load our Boot Table containing our application?

What is TI's ETA of when updated SPI Bootloader documentation and the wiki page will be available showing example SPI Booting of EVM C6657 application directly into DDR?

I am stuck on this SPI Boot issue as the amount of application code that I need to load requires being targeted to DDR memory.  I'm getting concerned that this might not be possible and that booting the C6657 in our h/w layout may need to be changed.  Our h/w layout decisions are needing to be made ASAP.

Thanks in advance for your help.

-George

George,

My answers are inline.

Arun,

I've been further reviewing the "evmc6657l.gel" and "evmc6657.c" to correlate these two sources to understand the DDR3 configuration taking place.

Both these perform virtually the same steps using the same register value initializations, except for the value written to DATA8_WRLVL_INIT_RATIO, i.e. DDR3_Config10.  The GEL script writes a value of 0x21 whereas the .C file uses a value of 0x1C.  I'm assuming that this is not a big difference and more than likely not what is causing my SPI Boot and subsquent CCS connect issue.  Indeed using either results in the same CCS connect failure.  Which value should be used?

<AVM> Please use the one in the .c file.

Some of the bit "toggling" taking place in these 2 references are not possible to be accomplished simply by our writing to the RBL DDR Configuration Table at address 0x008F_FD20 via the Boot Table.  I am assuming that these procedural steps are the responsibility of the RBL execution of transacting the DDR Configuration Table that we load into 0x008F_FD20.  Correct?

<AVM>  Yes

The "toggling" I'm referring to is the PHY reset bit 15 0->1->0 in DDR_PHY_CTRL_1.  Is this being accomplished by the RBL code?  I am assuming this is being done by the RBL.  Correct?

<AVM> Yes

Is it possible to SPI Boot application code directly into DDR3 memory by solely loading a Boot Table and not implementing an IBL (intermediate boot load) approach?  Or do we need to perform a Boot Config and re-enter RBL to load our Boot Table containing our application?

What is TI's ETA of when updated SPI Bootloader documentation and the wiki page will be available showing example SPI Booting of EVM C6657 application directly into DDR?

<AVM> No unless otherwise you have initialized the DDR, you cannot load the data.

I am stuck on this SPI Boot issue as the amount of application code that I need to load requires being targeted to DDR memory.  I'm getting concerned that this might not be possible and that booting the C6657 in our h/w layout may need to be changed.  Our h/w layout decisions are needing to be made ASAP.

<AVM> George, I would greatly appreciate, if you can wait till end of this month, I will try to get an update atleast on SPI boot and booting from DDR.

Thanks in advance for your help.

-George

Thanks,

Arun.

Arun,

I'm not quite sure about your answer to my question...

Is it possible to SPI Boot application code directly into DDR3 memory by solely loading a Boot Table and not implementing an IBL (intermediate boot load) approach?  Or do we need to perform a Boot Config and re-enter RBL to load our Boot Table containing our application?

<AVM> No unless otherwise you have initialized the DDR, you cannot load the data.

I was *not* asking the trivial question if application code could be loaded into "uninitialized" DDR memory.  I am completely aware that DDR memory *must* be initialized first.  My intended question was specifically whether this DDR initialization *can* be accomplished via providing the RBL DDR Configuration table using only the Boot Table mechanism -OR- must we use a Boot Config and secondary boot RBL/IBL.  Is it possible to use an SPI Boot Table only for this, i.e config DDR and then load code/data into DDR within the same Boot Table?

I still need to find out how to force the linker/tools to arrange the Boot Table such that the DDR Configuration table section is placed prior to application code/data sections targeting DDR.  How is this accomplished?

Thanks for the ETA on updates for C6657 SPI Boot to DDR.  Waiting until the end of the month is not advantageous to our schedule.  Anything that can be provided sooner would be greatly appreciated.  Is there anyone else that can work on answering these questions sooner?

-George

Hi George.

I don't have much time to explain you.
but quickly ,  I saw {mcsdk_****}/tools/post/evmc6657/bin/post_romparse.bat
It figgures how to make .out  to Boot table(for RBL)
I lernd about rom boot table. and how to make boot table.

This can't include DDR setting table automatic, I've hand editted the file generated on the way.
between Entrypoint and the first section of my program.

Possibly it was a binary editor although I could not remember.

and I 've made single bootfile include following (For 6678 but I think almost same mechanizm)
1. Boot Parameter table
2.Entry Point of my program
3.DDR3 Setting for RBL (one section in BootTable)
4.My original program (for single core)

later, I made my original generation tool(win32)  for multi core.(Sorry but I cant provide you)

Best Regards,
Kazunori.

Kazunori,

Thanks for the post and confirmation as to the makeup of the Boot Table.  I agree with your approach.

The "post_romparse.bat" command file is what I referenced early on to understand the TI step/utilities to follow in creating a boot image (parameter table + boot table).

This as I've stated in my postings earlier isn't my problem.  I have created a boot image and witness C6657 SPI reading this binary data into DSP internal memory as expected.

I've created a ddrcfg.s (assembly file attached earlier) to represent the DDR Configuration table to be linked in.  This is happening as expected and landing in RBL memory at 0x008F_FD20. 

One problem I'm having is how to have the TI linker to arrange this .ddrcfg section to be located prior to the application sections.  This is *obviously* required as DDR memory is needed to be enabled prior to loading application code/data into DDR3.

I agree and understand that DDR Configuration section of Boot Table *must* be placed immediately following Boot Table Entrypoint.  This is what I want the linker/utilities to perform for me.  This is the question I've stated on my post on Dec 5th...

Do you know a way that I can direct the linker (or other tool) to arrange these sections such that the required DDR Configuration table becomes the first section within the Boot Table.  I know that I could manually fix this ordering in the process by rearranging the sections prior to "b2i2c" running, but that would be clunky.  There should be a way to accomplish this using the linker, but how?

I realize that I could manually perform this step by hand-editing the input to "b2i2c" and have done this very thing, but would like to have it be automated using the TI tools.  This should be possible.  This is my goal and request.

The other problem I'm having regardless of Boot Table section arrangement, is that the DDR Configuration that I'm providing for the C6657 (per Arun's doc and GEL/.C code) seems not to be enabling DDR3 memory.  At least when I set the "EnableBitMSW" to non-zero and perform SPI Boot I cannot subsequently attach via CCS/JTAG receiving the "core hung" message.

Thanks,

-George

Hi

befor DDR Setting table, your boot parameter table has some probrems.
first , 4.Boot mode shuld be 0x0032, see Table3-20 of  bootloader UG
   aand PLL COONF(MSW)=0x8014 , PLL Config Ctl= "10"b and mult shuld be 0x14 (100MHz x 20) / 2
Next ,
I prefer beleaving TI source code  rather than bleleaving TI documents.It's because TI stuffs use the source code, and it works.
My boss gives me time to DIY. becouse he knows qualty of TI documents,and unknown erratas for his long time using ti device.
I read romparse.exe's output, and RBL source code(sometimes trace RBL (disassembly).
And I found some misleadings of TI docs,
-offset 40 Mode is already mooved to ofset 20(undocumented), 0ffset 14 is Address width
-Address Width should be 0x0018 (undocumented)
-NPIN is  to be 4 or 5(not 3 or 4)
Welcome to TI world.

about DDR3 , pls see http://e2e.ti.com/support/dsp/c6000_multi-core_dsps/f/639/t/193796.aspx

Kazunori,

Regarding your parameter table comments/issues I think I've gotten beyond those as I've stated in my later posts.  Early on I was following the erroneous SPRUGY5B documentation per SPI.  Per Arun's comments I've referred to the RBL source (C6670 and C6678).  The tboot.h has provided me with expected SPI Boot behavior.

My target is the EVM C6657 which per Arun does not follow other Keystone devices at least in regards to SPI and DDR Configuration.  With this said I still don't know how valid it is to extrapolate information being found in the RBL source provided for the C6670 and/or C6678.  The RBL code for the C665x may be different.  TI has *not* provided the RBL source code for the C6655/7.

Regarding the PLL settings I've also had concerns as to what the settings are.  I have had success with PLL Config Ctl bits being set to either 01b (configured if bypass/diabled) or 10b (configured).  In either case the PLL seems to be configured properly in the end.  This is the case because as I understand in SPI Boot mode the PLL is being placed in bypass upon boot up.  So in either case, the RBL in SPI mode will then apply the PLL Mult, Pre-Div, and Post-Div provided in parameter table.

I'm using PLL Config=10b, Mult=19, Pre-Div=0, Post-Div=0 to achieve the EVM's 1000 MHz clockout.  I see that you recommend Mult=20, but per SPRS814A on page 33 it shows the CLK calculation being as follows.  With CLKIN=100 and PLLM=19, OUTPUT_DIVIDE=2 (see SECCTL default reset value 1 = divBy2), PLLD=0

CLK = CLKIN × (PLLM+1) ÷ (OUTPUT_DIVIDE × (PLLD+1)) ==> 100 * (19+1) / (2 * (0+1)) ==> 100 * 20 / 2 ==> 2000 / 2 ==> 1000

My goal is to get 1000 MHz which my PLL settings should provide.  Furthermore, referring to the DDR PLL Configuration Field Descriptions table in Arun's recently provided DDR_Configuration_for_C6657 word document, you can see clearly that the encoding of the values are being provided as "minus 1" not "plus 1" as you're suggesting.  In other words, if you want a value of 20 as the multiplier one needs to provide Mult=19, i.e. 20-1, as I've done.  This is because a 1 is being added to whatever is provided.  Likewise, the Post-Div=0 will yield a Post-Divider of 1 which is what we want given the above calculation and the following DDR PLL Config definition which seems to correlate with Table 2-7 PLL Configuration within the SPRUGY5B.

At the moment I'm struggling with the DDR Configuration field "PLL Config" at byte offset 12.  This reportedly follows the above field definition and bit-field layout.  Currently, I'm programming this register with a value of 0x80270002.  This says that the "0b10 = PLL is Configured", Mult=39, PostDiv=2.  These values I've taken from the GEL used for the EVM C6657 for 1333 MHz.  Whenever I enable the use of this field, i.e. setting bit0 within EnableBitMSW, upon SPI Boot I cannot connect via CCS/JTAG getting "core hung".

If I disable this field I can connect successfully via CCS/JTAG, but upon accessing DDR3 it is not enabled.  So, it appears the "core hung" connection problem that I'm having is related to the DDR PLL configuration setting I'm using.  I've tried many variations but with no luck.

What is the value I should be using for the DDR PLL Configuration field when running on the EVM C6657?

-George

hi  George
I've misstaken because your first post was shown top of the second page, before your latest post for me. so I 've comment your first post. sorry.

and thanks for pointng me thins core pll (-1) , but 6678RBL automatically  (-1) for mult  and set to pll register, so, it proposes for 1GHz.

according to your post on Dec 10 2012 11:24 AM ,

0x00270002(pll) seems to be offset 4bytes to right , from arun's word docx.
If it is also my lack of reading this thread,  i msut appologize.
Kazunori

Kazunori,

The reason for the right shift of the PLL_Config value is due to the 32-bit "checksum" values being inserted by "b2i2c" tool to support RBL's SPI loading of the Boot Table.  In that post the Green highlighted/italiced values are the checksum's being inserted by "b2i2c" utility step.  For the purposes of data alignment auditing of the DDR Configuration table per Arun's document you'll need to discard these 32-bit "checksum" values.

-George

Arun,

I was wondering if you had a chance to work on the C6657's SPI Boot and DDR Configuration wiki and/or example.  It's now the end of the month/year in which you suggested this effort would be completed.  I've still been unable to successfully configure the DDR3 and SPI boot load my application into that DDR3 using the EVM C6657.  I consistently can not connect via CCS/JTAG witnessing the error "core hung".  It is unclear at the moment if there is a register not being set properly or some other undocumented behavior needing to be following.

Your help in resolving this issue would be greatly appreciated.

-George

Hi George,

Sorry for the delay. I am trying to get an exampe for SPI boot with the code loaded in DDR. Will this example will help you in getting your code? Please advise. With that example, I am getting a SPI boot document updated.

THanks,

Arun.

Arun,

I am not completely sure what you are asking for here.

The "simple" application that I am using is in the attached zip file along within my build procedure.  Currently, it is being targeted to internal L2 memory 0x00810000, but the end goal is to target loading into DDR3 memory at 0x80000000 via changing "simple.cmd".

The DDR Configuration being used is contained within "ddrcfg.s" and being located to 0x008FFD20 using the same "simple.cmd" linker command file.

NOTE:  I have NOT found a way to direct the linker to place the .ddrcfg section prior to application code/data (.text and .data) sections within the resulting Boot Table.  This remains a mystery and a problem needing a solution.

Here's my latest zip file...

1641.mySpiBoot_201301071741.zip

If this is not what you're asking please let me know.

Thanks,

-George

George,

The boot table goes from the lowe address to the higher one. So the ddr cfg will be the first one that will be loaded. The first 3 words are trigger value, once they are non zero, they will trigger the ddr configuration. Then the boot loader will continue the next section which will be loaded in the DDR. Also what is the size of the DDR cfg structure. Does it fit in one 0x80 byte block?

Thanks,

Arun.

Arun,

The boot table goes from the lowe address to the higher one. So the ddr cfg will be the first one that will be loaded.

<George's reponse> This behavior would be desirable, but is NOT what I am experiencing.  My experience is that the boot table is being generated by the TI utilities maintaining the same section ordering as present within the COFF file "simple.out" which is NOT being section-ordered from low to high addresses.  I have changed the "simple.cmd" linker command file targeting the .text/.data to DDR memory 0x80000000 which has *not* fixed the section load ordering problem.  When I do that the boot table still has the .text/.data sections prior to the .ddrcfg section.  If you could share with me how to direct the TI linker to accomplish this behavior, then this would solve the requirement of having the DDR Cfg boot table section loaded prior to subsequent sections targeting DDR memory.  How do I tell the linker to perform this "ordered" low-to-high addressing within COFF file and hense the boot table?  Or is this accomplished by one of the other TI utilities?

The first 3 words are trigger value, once they are non zero, they will trigger the ddr configuration. Then the boot loader will continue the next section which will be loaded in the DDR.

<George's response> I understand this is the trigger mechanism.  This is what I am expecting to happen by RBL.  Thanks for the confirmation.

Also what is the size of the DDR cfg structure. Does it fit in one 0x80 byte block?

<George's response> The DDR cfg structure (per your Word Doc) is 356 bytes and thus NO it will not fit within one 128 (0x80) byte block.  The example that I've provided has an assembly file "ddrcfg.s" which populates this 356 byte DDR Cfg table (89 32-bit words).  This .ddrcfg table is being located at 0x008FFD20 via the linker command file "simple.cmd".

Whenever I "enable" bit 0 of first trigger word, which corresponds to PLLCFG, the subsequent CCS/JTAG connection attempt following SPI Boot fails with "core hung".  Why?

-George

Hi George,

Are you using a pragma for DDR config. In this case the text will be in DDR, but only this section will be moved to the L2. Here is an example.

#include “tiboot.h”

#pragma DATA_SECTION (myDdrCfg, “.myDdrCfg”)

Const BOOT_EMIF4_TBL_T myDdrCfg = {

                0xabcd0001,       /* config select msw */

                0x1234000b,       /* config select slsw */

                  … etc

}

Create a section myDDRcfg in the linker cmd file and point to that area.

The reason that the boot fails has you mentioned is because the SPI transfers in blocks of 128 bytes. Since the trigger is always set in the first block, they start executing and they don't do full DDR initialization. So you can increase the block size by updating the b2i2c. Change the line below

blockSize = copyBlock (dataSet1, pIn, inSize, &block[4], 124);

to

    blockSize = copyBlock (dataSet1, pIn, inSize, &block[4], 0x400-4);

for 1k blocks.

See if these two helps.

Thanks,

Arun.

Arun,

I am using assembly file instead of a 'C' file for the DDR Config.  Please refer to my ddrcfg.s (see previously attached zip) in which I am creating a  .sect ".ddrCfg" which is being referenced within my linker command file "simple.cmd" and locating each discrete 32-bit words making up the DDR Config into memory starting at 0x008F_FD20.  This results in a single Boot Table section of size 0x164 starting at 0x008F_FD20.  This appears to me to be working properly and is landing into 0x008F_FD20 memory upon inspection via CCS/JTAG (that is when I disable PLLCFG).

Still the problem of ordering this .ddrcfg section prior to .text/.data sections within the Boot Table remains.  How do I enforce the .ddrcfg section to be loaded first in Boot Table to be transacted by RBL prior to sections targeting DDR memory?

Your suggestion of changing the "blocking" size used by "b2i2c" from 128 to 1024 did *NOT* fix my problem of attaching to EVM via CCS/JTAG when enabling PLLCFG following SPI Boot.  Obviously, the DDR configuration PLLCFG is still causing a problem.

This recommendation of changing the blocking size to fix my boot failure does not make sense to me.  This would suggest that the RBL is checking the "enable" triggers within DDR Config following each "block" which as it turns out is quite arbitrary since we can change this to whatever we want by altering "b2i2c".  The reason it does not make sense is that the "blocking" size is an arbitrary size regardless of the boot table section being loaded, i.e. sections will not be equal to blocks nor be aligned on a block size boundary.  Sections would conceivably require mulitple blocks to be loaded completely.  It would be extremely difficult to imagine that the RBL would check to enable DDR memory following a block size load, but rather it makes sense that it perform this check following each boot table section processed.

The SRPUGY5B Bootloader documentation clearly says that the RBL checks the DDR Config "enable" bitmap field after every "boot table section is complete" and not after each "block" size.  I know that the SPRUGY5B has erroneous information, but is the paragraph at the bottom/top of pages 2-3 and 2-4 incorrect?  If so, I had asked about this several times and many posting ago.  To be clear, what is the RBL mechanism being used for checking DDR Config.  I don't have access to the RBL code for the C6657 so I am unable to verify.  Please advise.

Here's the passage I'm referring to which clearly states "after every boot table section is complete"...

The bootloader also has a DDR configuration table that, by default, is initialized to all zeros. During the bootloader process, the parameter table is polled after every boot table section is complete. The DDR3 is configured if the bootloader finds that the enable bitmap field is non-zero. This allows a single boot table to configure the DDR table, then load data to DDR. The DDR configuration boot parameter table is shown in Table 2-3.

-George

HI George,

I saw your cmd file. The BYTE1 is in L2 and is still in the lower address than DDR cfg. That is the reason this is happening. Put the BYTE1 in 0x80000000 that should work.

Thanks,

Arun.

Arun,

I have tried this and this does NOT fix the Boot Table section ordering problem.

I have modified my linker command file "simple.cmd" as you have suggested to locate .text/.data to DDR memory.  This I have done many times already with NO success, and below is the binary data file which results.

The linker command file "simple.cmd" is changed to locate .text to 0x80010000, .data to 0x80010100, .byte1 to 0x80010201, and .byte2 to 0x80010210 and here's what I get.

The binary hex dump below is the contiguous byte stream of app.bin which is shown simple broken up for annotation purposes.

SPI Boot Parameter Table starting at byte offset 0...

0x00280000 0x00320000 0x40130000 0x00010018 0x00040000 0x00020000 0x03e80032 0x00000000 0x00280000 0x00000000

"b2i2c" blocking checksum 32-bit entry (using new 1024 blocksize) at byte offset 40...

0x01e486c9

Boot Table at byte offset 44...

Here's the "jump" address which is the entry point to the "simple" app being loaded (notice DDR3 memory address)...

0x80010000

Here's the .text section (notice it starts at a HIGHER address than the DDR Config section at end) ...

0x00000040 0x80010000 0x0099a228 0x00889168 0x010100a8 0x014000e8 0x01080226 0x01810828 0x01c000e8 0x018c3626 0x020c0226 0x0001a120 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000

Here's the .data section...

0x00000004 0x80010100 0x1234abcd

Here's the .byte1 section...

0x00000001 0x80010201 0x12000000

Here's the .byte2 section...

0x00000002 0x80010210 0x12340000

Here's the .ddrcfg section (notice the destination address is LOWER than the above earlier sections)...

0x00000164 0x008ffd20 0x0001417b 0x00ffd7fd 0x00000000 0x80270002 0x62477ab2 0x00000000 0x0000144f 0x1333780c 0x30717fe3 0x559f86af 0x00000000 0x00000000 0x00000000 0x00010000 0x00000000 0x00000000 0x00000000 0x70074c1f 0x00000000 0x0010010f 0x0010010a 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000305 0x0020000f 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000033 0x0000003a 0x0000002c 0x0000002c 0x0000001c 0x00000000 0x80000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x000000b7 0x000000b1 0x000000a4 0x000000a4 0x00000098 0x00000200 0x00000015 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000

Here's the Boot Table termination 32-bit zero record...

0x00000000

As you can clearly see the .ddrcfg section within the Boot Table above happens AFTER the sections loading code/data into DDR3 memory.  This is a problem for the RBL as DDR3 memory will not be enable prior to load code/data into DDR3.

I hope this is evidence enough that simply changing the linker command file is NOT enough to affect the desired ordering of sections within the Boot Table as I understand how the TI utilities are needing to be used presently.  There must be another mechanism to affect the desired section ordering within the Boot Table, but what is that mechanism?

-George

George,

I am trying to get you a example code for this. Just for compariosn, can I get your boot table? Will try to get the code by tomorrow.

Thanks,

Arun.

Arun,

Here's my latest SPI boot example.  The "simple" app it being targeted to DDR3 and the DDR Config has PLLConfig enabled.  Refer to "app.bin" within the attached zipped folder.  This is the binary image resulting from my build process which norwritter writes into the EVM's NOR Flash.  This "app.bin" contains the SPI Boot Parameter Table and the Boot Table immediately following.

5023.mySpiBoot_201301151204.zip

I hope this is what you are looking for.

I hope that you will be able to take at look at my attached example and tell me why it doesn't work instead of me inferring what is wrong with it by looking at the example you'll be providing.  My example is quite simple and straight forward.  It should work per the information TI has provided so far, but doesn't. 

I look forward to your example.

Thanks for the help.

-George 

George,

One more thing in you ddr config code is that you are setting PLLM=39, Prediv = 1, post div to 2. It is okay for the gel as we go and set the registers. but for the boot rom it should PLLM=40, Prediv = 1 and postdiv = 3.

I am close to complete the example code. I just want to see if this setting help to run your code.

Thanks,

Arun.

Arun,

The current input value I've been using for DDR_Config.PllCfg isn't exactly as you've stated, but rather the following.  I was understood the input values needed to be provided in "minus-1" form in anticipation of +1 being added by system when used (per your DDR_Configuration_for_C6657.doc within table "DDR PLL Configuration Field Description" on page 3).  Given this I presummed that I needed to provide the following "minus-1" input in order to acheive PLLM=39+1=40, PreDiv=0+1=1, and PostDiv=2+1=3 as you're suggesting is needed.

0x80270002 (Ctl = 01, PLLM = 39, PreDiv = 0, PostDiv = 2)  ... provided in "minus-1" form anticipating +1 to be applied to each

Notice that I was setting PreDiv=0 and not 1.  I believe this is what's needed.

Regardless, I changed inputs to the following leaving PreDiv=0,  and I still get CCS/JTAG "core hung" upon connection attempt

0x80280003 (Ctl = 01, PLLM = 40, PreDiv = 0, PostDiv = 3)

I then changed inputs explicitly to the following with the same CCS/JTAG "core hung" upon connection attempt

0x80280103 (Ctl = 01, PLLM = 40, PreDiv = 1, PostDiv =3)

Here's the popup error message I get when I attempt to connect to EVM following SPI Boot attempt...

Error connecting to the target: (Error -1143 @ 0x0) Device core was hung. The debugger has forced the device to a ready state and recovered debug control, but your application's state is now corrupt. You should have limited access to memory and registers, but you may need to reset the device to debug further. (Emulation package 5.0.872.0)

I think my original input settings of PLLM=39, PreDiv=0, PostDiv=2 are correct to in order to achieve your recommended runtime settings PLLM=40, PreDiv=1, PostDiv=3.

What values do you think is needed for DDR_Config.PllCfg fields ... PLLM, PreDiv, PostDiv?

The other question I have is what value to use for the field PLL_Config_Ctl, I've tried all settings in the past and decided to use 0b10 "PLL is configured".

What value should I be using for the field "PLL_Config_Ctl"?

You should be able to modify my files provided (simple.cmd, ddrcfg.s) and rebuild on your end and program into EVM C6657 using norwriter and see if you can get it succeed.  My example is very straight forward and as minimal as it can get.

-George

HI George,

That was I though too. But The values for boot should always be the original value. So the PPLM=40, Prediv=1, Post Div = 3. I have pasted the structure I got. I am still testing it. But was verified in our design board.

#pragma  DATA_SECTION (emif4Cfg, ".emif4Cfg")
const BOOT_EMIF4_TBL_T  emif4Cfg =  {

    BOOT_EMIF4_ENABLE_MSW_pllCtl          | \
    BOOT_EMIF4_ENABLE_MSW_sdRamTiming1    | \
    BOOT_EMIF4_ENABLE_MSW_sdRamTiming2    | \
    BOOT_EMIF4_ENABLE_MSW_sdRamTiming3    | \
    BOOT_EMIF4_ENABLE_MSW_ddrPhyCtl1      | \
    BOOT_EMIF4_ENABLE_MSW_sdRamRefreshCtl | \
    BOOT_EMIF4_ENABLE_MSW_sdRamConfig,

    0,      /* Config select slsw */
    0,      /* Config select lsw  */
    
    1,      /* pllPrediv  */
    40,     /* pllMult    */
    3,      /* pllPostDiv */

    0x62477AB2,  /* sdRamConfig */
    0,           /* sdRamConfig2, dont care*/
    0x144F,      /* sdRamRefreshCtl  */
    0x1333780C,  /* sdRamTiming1 */
    0x30717FE3,  /* sdRamTiming2 */
    0x559F86AF,  /* sdRamTiming3 */

    0,           /* lpDdrNvmTiming, dont care */
    0,           /* powerManageCtl, dont care */
    0,           /* iODFTTestLogic, dont care */
    0,           /* performCountCfg, dont care */
    0,           /* performCountMstRegSel, dont care */
    0,           /* readIdleCtl, dont care */
    0,           /* sysVbusmIntEnSet, dont care */
    0,           /* sdRamOutImpdedCalCfg, dont care */
    0,           /* tempAlterCfg, dont care */

    0x0010010F,  /* ddrPhyCtl1 */

    0,           /* ddrPhyCtl2, dont care */
    0,           /* priClassSvceMap, dont care */
    0,           /* mstId2ClsSvce1Map, dont care */
    0,           /* mstId2ClsSvce2Map, dont care */
    0,           /* eccCtl, dont care */
    0,           /* eccRange1, dont care */
    0,           /* eccRange2, dont care */
    0,           /* rdWrtExcThresh, dont care */

    0, 0, 0, 0, 0, 0, 0, 0,
    0, 0, 0, 0, 0, 0, 0, 0,
    0, 0, 0, 0, 0, 0, 0, 0,
    0, 0, 0, 0, 0, 0, 0, 0,
    
    0, 0, 0, 0, 0, 0, 0, 0,
    0, 0, 0, 0, 0, 0, 0, 0,
    0, 0, 0, 0, 0, 0, 0, 0,
    0, 0, 0, 0, 0, 0, 0, 0
};

Thanks,

Arun.

Arun,

I have a question regarding your PllCfg field within your DDR Config table provided.

1,      /* pllPrediv  */

40,     /* pllMult    */

3,      /* pllPostDiv */

WIthout know what the typedef BOOT_EMIF4_TBL_T actually is these entries could be 3 discrete 32-bit fields, i.e. one for each PllPrediv, pllMult, and pllPostDiv, or bit fields within a single 32-bit element.  If the latter, then this would suggest that the "pllPrediv" is the LS-Bits and "pllPostDiv" is the MS-Bits of that 32-bit field.

But, your DDR_Configuration_for_C6657.doc and table "DDR PLL Configuration Bit Fields" suggests quite the opposite and a *very* different layout as follows

PLL_Cfg_Ctl [ bits 31, 30 ]

PLL_Mult [ bits 29 - 16 ]

PLL_Pre-Div [ bits 15 - 8 ]

PLL_Post_Div [ bits 7 - 0 ]

This documented bit field definition is what I've been using.

So, what is the actual implementation?  Is PLL_Cfg_Ctl present or not?
What is the typedef for BOOT_EMIF4_TBL_T data structure being used in your table declaratoin provided?

Does the resulting 32-bit field for PllCfg look like this 0x03002801?  If so, I have loaded your table with this value implementation for PllCfg and I still can not CCS/JTAG connect following an SPI Boot getting "core hung".

Possibly are there 3 discrete 32-bit fields, i.e. one for each pllPrediv, pllMult, and pllPostDiv?  If so, I don't see a corresponding bit-enable being specified within EnableBitmapMSW, i.e. the first "enable" 32-bit entry within the DDR Config.

Here's another observation.  Assuming the use of a single 32-bit field for PllCfg, your table as provided has 92 32-bit fields for a total size of 368 bytes.  In comparison what I've been using for my DDR Config table (per your word doc) is 89 32-bit fields for a total size of 356 bytes.  Which is correct?

Please clarify your new table definition/size and in particular the PllCfg field definition.

-George

Hi George,

I am deeply sorry about the confusion. Seems like the dev plan document and the actually development did not match. The structure should be the one I gave recently. ALso all the boot parameter structure definition are available in MCSDK. the path is C:\MCSDK\mcsdk_2_1\mcsdk_2_01_02_05\tools\boot_loader\ibl\src\device. In this folder there are folder for each device. You should look at C665x folder. You will have a tiboot_665x.h file. I checked that there is no PLL cfg and the 3 values are defined as uint32. Also i checked the code where they are setting the PLLs and can see that they are using this variable as such instead of adding 1 to it as it was always done. So please set the PLLM, prediv and postdiv as such. I am deeply sorry that the document din't match. I hope this change would really solve the issue you are facing. Please let me know the status.

Thanks,

Arun.

Arun,

Thanks for the clarification.  The typedef for BOOT_EMIF4_TBL_T does help to clarify the emif4Cfg data structure that you provided.

I agree the documentation was misleading and the 'configSelect_msw' field is a little inconsistent in that bit 0 controls all three "pllPrediv", "pllMult", and "pllPostDiv" 32-bit entries.  Bit 1 controls "sdRamConfig" and so forth.  This clears up how this behaves.  Assuming that this is what the RBL expects to see for DDR Config at 0x008FFD20 during Boot Table section processing, then things should work correctly, but low and behold I still have problems.

Doing this has *not* solved my orginal DDR Config via Boot Table problem.  Loading the following into NOR flash, performing an SPI Boot and subsequent CCS/JTAG connect results in the annoying message "core hung".

Here's the annotated hex dump of "app.bin" SPI Boot Parameter Table and Boot Table.

... SPI Boot Parameter Table ...

0x00280000 0x00320000 0x40130000 0x00010018 0x00040000 0x00020000 0x03e80032 0x00000000 0x00280000 0x00000000

0x01f8674f  <<=== Checksum inserted by "b2i2c"

0x80010000 <<=== Jump To DDR3 Address after loading all Boot Table sections

0x00000040 0x80010000 0x0099a228 0x00889168 0x010100a8 0x010040e8 0x01080226 0x01810828 0x018040e8 0x018c3626 0x020c0226 0x0001a120 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000

0x00000004 0x80010100 0x1234abcd

0x00000001 0x80010201 0x12000000

0x00000002 0x80010210 0x12340000

... DDR Config (section) ...

0x00000178 0x008ffd20

0x0001007b 0x00000000 0x00000000 0x00000001 0x00000028 0x00000003 0x62477ab2 0x00000000 0x0000144f 0x1333780c 0x30717fe3 0x559f86af 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x0010010f 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000

... Termination Record ...

0x00000000

Notice that I am using your "exact" DDR Config table provided.  This has not fixed my "core hung" problem.

I still have the issue whereby the DDR Config section within the Boot Table is located after the code/data sections being target to DDR3 memory.  This is a problem.  How do I get the linker to re-order the sections within the Boot Table?

I have an SPI logic analyzer attached and have confirmed that the RBL is correctly performing SPI read transfers as expected.

To make sure things are landing into DSP memory following this SPI Boot, I've changed my linker command file "simple.cmd" to locate code/data to internal L2 memory 0x00810000 and disabled the DDR Config "PllCfg" by setting 'configSelect_msw' to 0x0001007a.  Now, I can connect with CCS/JTAG without "core hung" and successfully inspect that the DDR Config table loaded correctly at address 0x008ffd20.  Likewise, the code/data loaded into internal L2 memory at 0x00810000 runs correctly placing the expected value 0x11223344 into register A1.

This proves that things are being created correctly, but for some reason the DDR Config table as processed by the RBL is causing the problem.  Simply by disabling "PllCfg" within the 'configSelect_msw" of the DDR Config table allows CCS/JTAG to connect successfully.

Any ideas why the DDR Config table I've provided above is not working?  It is *exactly* as you have suggested.

Could you please take my failing "app.bin" below and try loading it into your EVM C6657 and see if SPI Booting it works for you.  Can you CCS/JTAG connect afterwards?

... Here's the "app.bin" for NOR flash with DDR Config 'configSelect_msw' set to 0x0001007b (PllCfg enabled) ...  This one does *not* allow CCS/JTAG connection giving "core hung".  Here the application is being target to DDR3 memory at 0x80010000.

(2@
�2(
�gO�
@�
��(��h

�
@�
&
�(
��
�6&&
� �

4��
�

�
4
x�� 
{
(bGz�O3x0q�U���


... Here's the "app.bin" for NOR flash with DDR Config 'configSelect_msw' set to 0x0001007a (PllCfg disabled)... This one allows CCS/JTAG connection and can inspect 0x008ffd20 and application loading into internal L2 at 0x00810000 and executing successfully resulting in A1 = 0x11223344

(2@
�2(
�eR�@���(��h

�
@�
&
�(
�@�
�6&&
� �
4��
�
�4
x�� 
z
(bGz�O3x0q�U���


Do you have an example "app.bin" for NOR flash that you can provide me that demonstrates RBL is successfully SPI Booting an application directly into DDR3?  If so, I'd appreciate getting it and loading it onto my EVM to see how it works on my end.

Thanks,

-George

Hi George,

Sorry for the delay. I got the .dat file and I can see the ddr config section before the code itself. I am sorry I am still not successful in getting these code verified. i am having problems with my EVM. I am attaching the .dat and bin file in this mail. I will check your code once I get my board working.

Thanks,

Arun.

Forgot to add the attachment

.1055.spirom_le.swap.bin

5102.spirom_le_swap.dat

Thanks,

Arun.

Arun,

Thanks for providing your "example" .bin and .dat files.

I programmed your provided "spirom_le.swap.bin" into my EVM using norwriter and was able to connect using CCS/JTAG successfully, but upon inspecting where the Boot Table was directing the code/data into DDR3 I found that it wasn't there at address 0x80000000 and the reason was that your "spirom_le.swap.bin" did NOT have a DDR Config section within the Boot Table whatsoever to enable DDR3.  Upon inspecting 0x008FFD20 via CCS it was all zeros.

Why is your Boot Table missing the very much needed DDR Config section?

So, obviously your provided "spirom_le.swap.bin" is incomplete in demonstrating SPI booting an application directly into DDR3 as I was expecting.

Since I can CCS/JTAG connect following SPI Booting your .bin, this supports my hunch that there is an issue with the RBL's processing of the DDR Config table especially if the "BOOT_EMIF4_ENABLE_MSW_pllCtl" bit is enabled via the "configSelect_msw".  Obviously, this is NOT enabled in your .bin and I can CCS/JTAG connect.

I am assuming that you intend to incorporate the DDR Config section within Boot Table as part of your SPI boot to DDR3 example.  Correct?

Regardless your provided .bin and .dat are not helpful in demonstrating my desired goal of SPI booting and app directly into DDR3.

Did you have a chance to try out the two flavors of my "app.bin" that I provided recently?

-George

Arun,

Thank you for the confirmation that your earlier post of "app.bin" was missing a DDR Config section within Boot Table.

Yes, my EVM C6657's SW3 (pin1 - pin8) and SW5 (pin1 - pin8) match yours respectively, 1011 0000,  and 0010 0000.  (0=On, 1=Off)

Your latest "app.dat" does indeed demonstrate a successful SPI Boot directly from NOR Flash into DDR3 and run.  I have demonstrated this to work on my EVM C6657 which SW3 and SW5 settings above.  Now, I can connect CCS/JTAG without "core hung".  Thanks!!!

When will TI update the Keystone Architecture Bootloader User Guide - SPRUGY5B - fixing the erroneous SPI and other information ???

I understand your latest post's "spirom_le_swap.dat" has a manual modification of setting 'read_addr_msw' within SPI Boot Parameter Table to 0x0000.  This is, as you know, a bug within TI's "romparse" utility that I brought to your attention on this forum over a month ago.  The "bootbuild.c" application that I've provided was my alternative to TI's "romparse" utility having this issue.  I gave up on trying to fix "romparse" due to build issues I was having at that time and rolled my own "bootbuild" tool to provide the needed romparse functionality.

I look forward to your update to the TI "romparse" utility that fixes this 'read_addr_msw' error.

I've also made the same SPI Boot Parameter Table's 'read_addr_msw' alteration to your "spirom_le.swap.bin" and programmed it with norwriter_evm6657l.out and have verified that it works as well.

Your SPIboot_ddr.zip successfully demonstrates SPI Booting an application directly to DDR3.  Thanks!!!

I then looked at your spiboot.cmd and spiboot.asm and determined that my problem with forcing my DDRCFG section to occur prior to code/data sections within Boot Table was simply that I wasn't using the .sect directive in my DDRCFG.s but rather the .def directive.  The use of the .sect directive in my DDRCFG.s has now allowed the linker to arrange the sections per the ordering specified within my linker command file "simple.cmd."

Using the DDR Config settings from your post (many changes from your earlier posts) and by fixing my linker section ordering issue the resulting Boot Table has the DDR Config section before the code/data sections allowing the RBL to enable DDR3 prior to loading following code/data sections into DDR3.  Loading my resulting "app.bin" into NOR Flash and performing an SPI Boot to DDR3 has eliminated my CCS/JTAG "core hung" problem.  And more importantly my application code/data is being loaded directly into DDR3 and successfully executes.

Here's my simple "mySpiBoot" for completeness sake with updates.  I have successfully proven to SPI Boot this app directly to DDR3 on an EVM C5567.

5040.mySpiBoot_201301251826.zip

Thanks for your help in resolving this issue for me.

-George

George,

Glad to know that the example was useful and thanks for your sample example. I will focus on getting the the romparse working this week and then need to plan out the documentation delivery. I am hoping to get it done in a few weeks. i will keep you posted.

Thanks,

Arun.

Arun,

I found a bug in the "romparse.c" utility within the function assignKeyVal() at line 508 during the encoding of the SWPLL_PREDIV into the swPllCfg_lsw of the spi boot table.  The problem is that the pll_prediv value is being shifted too far to the left for storage into the upper MSB of the UINT16 field swPllCfg_lsw as can be seen in the following code snippet.

#if (defined(c66x) || defined(c665x))

        case SWPLL_PREDIV:    current_table.common.swPllCfg_lsw &= 0x00ff;

                                                 current_table.common.swPllCfg_lsw |= ((value & 0xff) << 16);        /* This left-shift should be changed to 8 */

                                                 break;

This same "romparse.c" bug appears in both mcsdk_2_01_00_03 and mcsdk_2_01_02_05.

I thought I'd bring this to your attention as you are updating "romparse.c" to address the read_addr_msw encoding problem found months ago.

Do you have a time-frame for when to expect updated "romparse" utility and "KeyStone Architecture Bootloader User Guide"?

-George

Hi George,

We just identified this bug this week. I am not sure how long will it take to get this going. I want to atleast put a note in the public wiki about the error. Were you able to compile after you made a change?

As for the document i am planning to get the rough draft out this mond end. But I will keep you posted on the status.

Thanks,

Arun.

Arun,

I did not try to re-build 'romparse' after fixing this issue as there are other problems such as read_addr_msw being generated incorrectly as you know.  I have not pursued fixing this utility awaiting your formal modification.

I am instead using my own replacement utility 'bootbuild' to accomplish my needs in creating the SPI Boot Parameter Table, etc.

#include <stdio.h>
#include <string.h>
#include <malloc.h>
#include "tiboot.h"

#undef  BOOT_PARAMS_SPI_OPTIONS_SHIFT
#define BOOT_PARAMS_SPI_OPTIONS_SHIFT (BOOT_PARAMS_SPI_OPTIONS_MASK - 1)

#undef  BOOT_PARAMS_SPI_SET_BOOTTBL_MODE
#define BOOT_PARAMS_SPI_SET_BOOTTBL_MODE(options, mode)              \
		(options) = ((options) & BOOT_PARAMS_SPI_OPTIONS_MASK) |     \
                    (((mode)   & BOOT_PARAMS_SPI_OPTIONS_MASK) <<    \
                                 BOOT_PARAMS_SPI_OPTIONS_SHIFT)

/*
- This simple application "prepends" a "Boot Parameter Table" and concatenates this BPT with
a .ccs file creating the resultant output file i2crom.ccs.
- The specification for the BPT is provided via the .map file specified on the command line.
*/

BOOT_PARAMS_SPI_T     spiBootParamTable;
char                  szExeFile[1024];

/*************************************************************************************
 * Declaration: The base address of the i2c ROM being created. This is just
 *              the I2C bus address. The default is 0x50
 *************************************************************************************/
int i2cRomBase = 0x00000050; //IBL_CFG_I2C_MAP_TABLE_DATA_BUS_ADDR;

FILE *yyin;
char line[1024];

/*************************************************************************************
 * Declaration: The next free address in the ROM for general data usage. For the
 *              start address there is room for the initial boot parameter tables, 
 *              plus room for the PCI eeai config.
 *************************************************************************************/
int romBase = 0x03000000; //DATA_BASE;

/*************************************************************************************
 * Declaration: Args passed in from the command line
 *************************************************************************************/
char *inputFile;
int   compact = 0;

/*************************************************************************************
 * Declaration: The value used to fill gaps in the file. For some devices this
 *              value must be set to 0xff so subsequent writing to these gaps will work
 *************************************************************************************/
unsigned char fillVal = 0;

/************************************************************************************
 * FUNCTION PURPOSE: Read an integer value from a string
 ************************************************************************************
 * DESCRIPTION: A decimal or hex value is scanned
 ************************************************************************************/
int readVal (char *s)
{
  int ret;

  if ((s[0] == '0') && (s[1] == 'x'))
    sscanf (&s[2], "%x", &ret);
  else
    sscanf (s, "%d", &ret);

  return (ret);

}

int isFieldAndValue(char *szIn, char *szField, int *val)
{
	char *pch;
	int offset = 0;
	int result = 0;
	
	pch = strstr(szIn,szField);
	if (NULL != pch)
	{
		offset = (int)pch - (int)szIn + strlen(szField);
		pch = strrchr(&szIn[offset],'=');
		if (NULL != pch)
		{
			offset=1;
			while (('\0' != pch[offset]) && (('\t' == pch[offset]) || (' ' == pch[offset]))) offset++;
			if ('\0' != &pch[offset])
			{
				*val = readVal(&pch[offset]);
				result = 1;
			} /* if */
		} /* if */
	} /* if */
	
	return (result);
	
} /* isFieldAndValue() */

int isFieldAndString(char *szIn, char *szField, char **szString)
{
	char *pch;
	int offset = 0;
	int result = 0;
	
	pch = strstr(szIn,szField);
	if (NULL != pch)
	{
		offset = (int)pch - (int)szIn + strlen(szField);
		pch = strrchr(&szIn[offset],'=');
		if (NULL != pch)
		{
			offset=1;
			while (('\0' != pch[offset]) && (('\t' == pch[offset]) || (' ' == pch[offset]))) offset++;
			if ('\0' != &pch[offset])
			{
				*szString = &pch[offset];
//printf("string @ offset=%d found:%s\n",offset,*szString);
				result = 1;
			} /* if */
		} /* if */
	} /* if */
	
	return (result);
	
} /* isFieldAndString() */

/******************************************************************************
 *
 * Function:
 *  ReadLine
 *
 * Description:
 *  Reads a line of characters from a file.
 *
 * Parameters:
 *  fp - Handle to an open file in the "rt" mode.
 *  line - location to store character read from fp.
 *
 * Returns:
 *  Negative - Error occured
 *  Positive - Number of characters read including '\0'
 *
 ******************************************************************************/
int ReadLine(FILE *fp,char *line)
{
    int ch;
    int count = 0;

    ch = fgetc(fp);

    if (EOF == ch)
    {
        count = -1;
    } /* if */
    else
    {
        while(('\n' != ch) && (EOF != ch))
        {
            *line++ = ch;
            ch = fgetc(fp);
            count++;
        } /* while */
        *line++ = '\0';
        count++;
    } /* else */

    return (count);

} /* ReadLine() */

int yyparse(void)
{
	int count = 0;
	int index = 0;
	int val = 0;
	int sectionStart = -1;
	int sectionOpen  = -1;
	int sectionEnd   = -1;
	char *pch;
	char *szStr;

	memset(&spiBootParamTable,0,sizeof(spiBootParamTable));
	
	/* Parse "section" */
	while (((count-index) >= 0) && (-1 == sectionEnd))
	{
		count = ReadLine(yyin,line);
		index = 0;
//printf("TOP ... count=%d, index=%d, line:%s\n",count,index,&line[index]);
		if ((count-index) > 0)
		{
			if (-1 == sectionStart)
			{
				if ((count-index) > 0)
				{
					pch = strstr(&line[index],"section");
					if (NULL != pch)
					{
						sectionStart = 1;
						index  = 7 + ((int)pch - (int)line);
//printf("SectionStart ... count=%d, index=%d, line:%s\n",count-index,index,&line[index]);
					} /* if */
				} /* if */
			} /* if */
			
			if (-1 == sectionOpen)
			{
				if ((count-index) > 0)
				{
					pch = strrchr(&line[index],'{');
					if (NULL != pch)
					{
						sectionOpen = 1;
						index  = 1 + ((int)pch - (int)line);
//printf("SectionOpen ... count=%d, index=%d, line:%s\n",count-index,index,&line[index]);
					} /* if */
				} /* if */
			} /* if */
			
			else
			{
				if ((count-index) > 0)
				{
//printf("Fields ... count=%d, index=%d, line:%s\n",count-index,index,&line[index]);
					if (isFieldAndValue(&line[index],"boot_mode",&val))          {spiBootParamTable.boot_mode           = val;}
					if (isFieldAndValue(&line[index],"param_index",&val))        {spiBootParamTable.portNum             = val;}
					if (isFieldAndValue(&line[index],"sw_pll_flags",&val))       {spiBootParamTable.swPllCfg_msw       |= (UINT16)(0x0000C000 & (val<<14));}
					if (isFieldAndValue(&line[index],"sw_pll_mult",&val))        {spiBootParamTable.swPllCfg_msw       |= (UINT16)(0x00003FFF & (val<<0));}
					if (isFieldAndValue(&line[index],"sw_pll_prediv",&val))      {spiBootParamTable.swPllCfg_lsw       |= (UINT16)(0x0000FF00 & (val<<8));}
					if (isFieldAndValue(&line[index],"sw_pll_postdiv",&val))     {spiBootParamTable.swPllCfg_lsw       |= (UINT16)(0x000000FF & (val<<0));}
					if (isFieldAndValue(&line[index],"options",&val))            {spiBootParamTable.options             = val;}
					if (isFieldAndValue(&line[index],"addr_width",&val))         {spiBootParamTable.addrWidth           = val;}
					if (isFieldAndValue(&line[index],"n_pins",&val))             {spiBootParamTable.nPins               = val;}
					if (isFieldAndValue(&line[index],"csel",&val))               {spiBootParamTable.csel                = val;}
					if (isFieldAndValue(&line[index],"mode",&val))               {spiBootParamTable.mode                = val; /*BOOT_PARAMS_SPI_SET_BOOTTBL_MODE(spiBootParamTable.options,val);*/}
					if (isFieldAndValue(&line[index],"c2t_delay",&val))          {spiBootParamTable.c2tdelay            = val;}
					if (isFieldAndValue(&line[index],"core_freq_mhz",&val))      {spiBootParamTable.cpuFreqMhz          = val;}
					if (isFieldAndValue(&line[index],"bus_freq_mhz",&val))       {spiBootParamTable.busFreqMhz          = val;}
					if (isFieldAndValue(&line[index],"bus_freq_khz",&val))       {spiBootParamTable.busFreqKhz          = val;}
					if (isFieldAndValue(&line[index],"read_addr_msw",&val))      {spiBootParamTable.read_addr_msw       = (UINT16)(0x0000FFFF & (val<<0));}
					if (isFieldAndValue(&line[index],"read_addr_lsw",&val))      {spiBootParamTable.read_addr_lsw       = (UINT16)(0x0000FFFF & (val<<0));}
					if (isFieldAndValue(&line[index],"next_csel",&val))          {spiBootParamTable.next_csel           = val;}
					if (isFieldAndValue(&line[index],"next_read_addr_msw",&val)) {spiBootParamTable.next_read_addr_msw  = val;}
					if (isFieldAndValue(&line[index],"next_read_addr_lsw",&val)) {spiBootParamTable.next_read_addr_lsw  = val;}
					if (isFieldAndString(&line[index],"exe_file",&szStr))        {if('"'==szStr[0]) strncpy(szExeFile,&szStr[1],strlen(szStr)-2); else strcpy(szExeFile,szStr);}

					/* Are we done? */
					pch = strrchr(&line[index],'}');
					if (NULL != pch)
					{
						sectionEnd = 1;
						index = 1 + ((int)pch - (int)line);
//printf("SectionEnd ... count=%d, index=%d, line:%s\n",count-index,index,&line[index]);
					} /* if */
				} /* if */
			} /* else */
		} /* if */
	} /* while */
	
#if 1
	printf("length             =   %d\n",  spiBootParamTable.length);
	printf("checksum           =   %d\n",  spiBootParamTable.checksum);
	printf("boot_mode          =   %d\n",  spiBootParamTable.boot_mode);
	printf("param_index        =   %d\n",  spiBootParamTable.portNum);
	printf("sw_pll_flags       = 0x%04X\n",spiBootParamTable.swPllCfg_msw);
	printf("sw_pll_mult        = 0x%04X\n",spiBootParamTable.swPllCfg_msw);
	printf("sw_pll_prediv      = 0x%04X\n",spiBootParamTable.swPllCfg_lsw);
	printf("sw_pll_postdiv     = 0x%04X\n",spiBootParamTable.swPllCfg_lsw);
	printf("options            = 0x%04X\n",spiBootParamTable.options);
	printf("addr_width         =   %d\n",  spiBootParamTable.addrWidth);
	printf("n_pins             =   %d\n",  spiBootParamTable.nPins);
	printf("csel               =   %d\n",  spiBootParamTable.csel);
	printf("mode               =   %d\n",  spiBootParamTable.mode);
	printf("c2t_delay          =   %d\n",  spiBootParamTable.c2tdelay);
	printf("core_freq_mhz      =   %d\n",  spiBootParamTable.cpuFreqMhz);
	printf("bus_freq_mhz       =   %d\n",  spiBootParamTable.busFreqMhz);
	printf("bus_freq_khz       =   %d\n",  spiBootParamTable.busFreqKhz);
	printf("read_addr_msw      = 0x%04X\n",spiBootParamTable.read_addr_msw);
	printf("read_addr_lsw      = 0x%04X\n",spiBootParamTable.read_addr_lsw);
	printf("next_csel          =   %d\n",  spiBootParamTable.next_csel);
	printf("next_read_addr_msw = 0x%04X\n",spiBootParamTable.next_read_addr_msw);
	printf("next_read_addr_lsw = 0x%04X\n",spiBootParamTable.next_read_addr_lsw);
	printf("exe_file           =   %s\n",  szExeFile);
#endif
	
	return (0);
	
} /* yyparse() */

/************************************************************************************
 * FUNCTION PURPOSE: Parse the input arguments.
 ************************************************************************************
 * DESCRIPTION: Returns -1 on invalid args
 ************************************************************************************/
int parseIt (int argc, char *argv[])
{
  int i;

  if (argc < 2)  {
     fprintf (stderr, "usage: %s [-compact] [-rom_base x] [-fill <fillval>] inputfile\n", argv[0]);
     return (-1);
  }

  inputFile = NULL;  

  for (i = 1; i < argc;  )  {

    if (!strcmp (argv[i], "-compact"))  {
      compact = 1;
      i += 1;

    } else if (!strcmp (argv[i], "-rom_base"))  {
      i2cRomBase = readVal (argv[i+1]);
      i += 2;

    } else if (!strcmp (argv[i], "-fill"))  {
      fillVal = readVal (argv[i+1]);
      i += 2;

    } else  {

      if (inputFile != NULL)  {
        fprintf (stderr, "usage: %s [-compact] [-rom_base x] [-fill <fillval>] inputfile\n", argv[0]);
        return (-1);
      }

      inputFile = argv[i];
      i += 1;
    }
  }

  return (0);

}

/************************************************************************************
 * FUNCTION PURPOSE: Create a 32 bit value from the image array
 ************************************************************************************
 * DESCRIPTION: A 32 bit word in big endian format is created
 ************************************************************************************/
unsigned int formWord (unsigned int p, unsigned char *image)
{
  unsigned int v;

/* 
  v = (image[p+0] << 24) |
      (image[p+1] << 16) |
      (image[p+2] <<  8) |
      (image[p+3] <<  0) ;
*/

  v = (image[p+1] << 24) |
      (image[p+0] << 16) |
	  (image[p+3] <<  8) |
	  (image[p+2] <<  0) ;
	  
  return (v);

}

int createOutput(void)
{
	FILE *fpIn;
	FILE *fpOut;
	int i, count, a, b, c, d, num32BitWords, value;
	
	fpIn = fopen (szExeFile, "r");
	if (NULL == fpIn)
	{
		fprintf (stderr, "could not open file %s\n",szExeFile);
		return (-1);
	} /* if */
	
	fpOut = fopen ("i2crom.ccs", "w");
	if (NULL == fpOut)
	{
		fprintf (stderr, "could not open file %s\n","i2crom.ccs");
		return (-1);
	} /* if */
	  
	/* Obtain record from first line of .ccs */
	count = ReadLine(fpIn,line);
	sscanf(line,"%d %d %d %d %x",&a,&b,&c,&d,&num32BitWords);
	printf("from %s ... %d %d %d %d %d\n",szExeFile,a,b,c,d,num32BitWords);
	
	/* Update the boot table */
	spiBootParamTable.length         = sizeof(spiBootParamTable);
	spiBootParamTable.length        += 4 - (4-(spiBootParamTable.length % 4));
	spiBootParamTable.checksum       = 0;
	spiBootParamTable.read_addr_lsw  = spiBootParamTable.length;
	
	/* Output header record for .ccs */
	fprintf(fpOut,"%d %d %d %d %x\n",a,b,c,d,num32BitWords+(spiBootParamTable.length)/4);
	
	/* Output the spiBootParamTable  */
	value = formWord(0, (unsigned char *)&spiBootParamTable); fprintf(fpOut,"0x%08x\n",value);
	value = formWord(4, (unsigned char *)&spiBootParamTable); fprintf(fpOut,"0x%08x\n",value);
	value = formWord(8, (unsigned char *)&spiBootParamTable); fprintf(fpOut,"0x%08x\n",value);
	value = formWord(12,(unsigned char *)&spiBootParamTable); fprintf(fpOut,"0x%08x\n",value);
	value = formWord(16,(unsigned char *)&spiBootParamTable); fprintf(fpOut,"0x%08x\n",value);
	value = formWord(20,(unsigned char *)&spiBootParamTable); fprintf(fpOut,"0x%08x\n",value);
	value = formWord(24,(unsigned char *)&spiBootParamTable); fprintf(fpOut,"0x%08x\n",value);
	value = formWord(28,(unsigned char *)&spiBootParamTable); fprintf(fpOut,"0x%08x\n",value);
	value = formWord(32,(unsigned char *)&spiBootParamTable); fprintf(fpOut,"0x%08x\n",value);
	value = formWord(36,(unsigned char *)&spiBootParamTable); fprintf(fpOut,"0x%08x\n",value);
	
	/* Append the .ccs file to the output "i2crom.ccs" */
	for (i=0; i<num32BitWords; i++)
	{
		count = ReadLine(fpIn,line);
		//printf("%s\n",line);
		value = readVal(line);
		//printf("0x%08x\n",value);
		fprintf(fpOut, "0x%08x\n", value);
		//printf("from %s ... entry=%d ... 0x%08X\n",szExeFile,i,value);
	} /* for */

	fclose (fpIn);
	fclose (fpOut);
	
	return (0);
}

int main (int argc, char *argv[])
{


  /* Parse the input parameters */
  if (parseIt (argc, argv))
    return (-1);

  yyin = fopen (inputFile, "r");
  if (yyin == NULL)  {
    fprintf (stderr, "%s: could not open file %s\n", argv[0], inputFile);
    return (-1);
  }

  /* Parse the input description file */
  yyparse();

  /* Create the output file */
  createOutput ();

}

section {
 boot_mode = 50
 param_index = 0
 options = 1
 core_freq_mhz = 1000
 next_dev_addr_ext = 0x0
 sw_pll_flags = 1
 sw_pll_mult = 40
 sw_pll_prediv = 1
 sw_pll_postdiv = 2
 addr_width = 24
 n_pins = 4
 csel = 0
 mode = 2
 c2t_delay = 0
 bus_freq_mhz = 50
 bus_freq_khz = 0
 exe_file = "mySpiBoot.btbl.bcv64x.i2c.ccs"
}

I look forward to your corrected 'romparse' utility and KeyStone bootloader documentation.

-George

Hi,Arun,

I am now facing a problem which puzzles me a lot. I have added ddr configuration table to file generated by hex6x.exe immediately after the first 4 words(entry point). For evm6678 ,it works well .DDR is successfully initialized.But it failed to do that when I try evm6670.Should the ddr configruation table be modified when used in evm6670 ?

Below is my ddr configuration table I found form thread http://e2e.ti.com/support/dsp/c6000_multi-core_dsps/f/639/t/193796.aspx

00 00 00 70 00 87 35 00 02 42 80 F5 00 00 00 00 00 00 00 1C 00 00 00 02
63 06 2A 32 00 00 00 00 00 00 14 50 11 13 78 3C 30 71 7F E3 55 9F 86 AF
00 00 00 00 00 00 00 00 00 00 00 00 00 01 00 00 00 00 00 00 00 00 00 00
00 00 00 00 70 07 32 14 00 00 00 00 00 10 01 0F 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 10 00 00 00 00 00 00 00 00 00 00 00 00 00 03 05

thanks!

Hi,

I am also woking with spi&nor boot, and i am quite confused about the parameters prediv, mul and post div. What do these 3

para mean? How shall I drevie the acutal Clock Multiplier Factor from those 3 paras? For example, I successfully boot my

c6678 evm with a ddr init para table I found in the form.

The  para table I found from forum, the 3 field are set as follow:

00 00 00 00 // pll prediv

00  00  00  1c// pll mul

00 00 00 02 // pll postdiv

And the DDR input clk in C6678 evm is 66.667MHZ, so how do these 3 parameters(mul = 28, div =2 ??) work to derive the

needed 666.67Mhz ddr rate in EVM? And since I am gonna use spi boot on my own board with ddr input clk 200Mhz, how shall I

change this 3 parameters to create a 666.67Mhz ddr rate?

Thanks!

David Yang

Hi Arun

I have read the thread and downloaded the example, but I am not sure how to use the example or how to modify it.

I can see that the example refers to an older version of MCSDK (mcsdk_2_01_02_05), where I am using a slightly newer version (mcsdk_2_01_02_06). Can you tell me if the problems you mention with romparse have been fixed?

I would really appreciate it if you could write a small step-by-step guide on how to use your example, or even better created a CCS5 project that does all the steps :-) 

I am sure that I am not the only person that find all this bootloader stuff a bit confusing and therefore could benefit from a CCS5 example project that  creates a bootloader binary file that can be written to the NOR flash.

thaks

Jens

Hi Jens,

Yes you can use the newer version of MCSDK. The problem in Romparse is still not fixed, but since we have a work around, this shouldn't be a problem.

The zip file you mentioned should have a batch file that has the description of the steps that you need to do. Please let me know if that helps.

Thanks,

Arun.