TMS320C6657: Booting IBL(I2C) + App(SPI) Issues

Brad,

As a continuation to this old thread, https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1134430/tms320c6657-ddr3-configuration-of-the-rbl-or-ibl-for-booting-custom-hardware/4359530#4359530

For the first and foremost step, the external memory (DDR3)  has to be up-and-running when the platform test is executed on the custom hardware.

From the previous post, I could see that the output logs shows the external memory test "got failed" in your custom hardware.

Please follow the below FAQ except the fact that, it is prepared for Keystone-two devices.

https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1096375/faq-66ak2e05-how-to-calculate-the-ddr3-interface-registers-for-keystone-ii-devices-and-test-debug-on-keystone-ii-evm

1. Instead we have to follow the Keystone I DDR3 Initialization  guide -https://www.ti.com/lit/an/spracl8/spracl8.pdf

2. And the spread sheet given inside the "Keystone I DDR3 Initialization  guide".

---

It will be more meaning ful, to discuss about the questions posted above, after the DDR3 is up. Because even for IBL + app --> I2c method, the app is flashed into the NOR using the same NOR-writer utility----> for which the DDR3 is required.

Regards

Shankari G

I have been looking into how the IBL configures the DDR3 memory.  As best I can determine there are two locations where the DDR3 configuration is set.

1. In the device.c file there is a configuration function, c6657_ibl_config(), as part of this function it appears to set configuration values for the DDR's interface (lines 1181-124).
2. In the emif4.c file there is a function, hwEmif4p0Enable(), that appears to set the EMIF's configuration.  In this function it appears that if the detected device is a C6657 the configuration structure is superseded and the EMIF is configured in a similar manor to that of the GEL file.

Am I reading the code correctly in that the configuration of the emif in the device.c file is not needed and I need to configure the EMIF in teh emif4.c file?

Brad,

Let me first review your DDR3 registration calculation in the spread sheet ( Which you have provided in the other thread. ) 

Then, the DDR3 registration values should be feed into the gel file of the custom hardware ( sarogotta.gel ) .

Next, will run few DDR3 memory test. ( Which is included in the gel as well as will do some read-write test of the complete DDR3 memory. ) 

Next, will run the platform test  ( Will make sure that the "External memory test" is passed,  as the external memory test fails, now.... in the custom hardware ).

Once these things are through, let us proceed to the modification of IBL source code.

IS this approach OK ?

( Let us not have two threads running in e2e. Let it me one. Either this one or the previous one.)

Regards

Shankari G

While I agree that a single conversation is desirable.  I am working with two treads to keep my thoughts straight as to which boot configuration I am working with at the time (i.e. this thread is for when booting the IBL from the I2C memory, the other thread is for when booting directly from the SPI memory.  I understand that there is overlap between the threads and that whatever the issue I am having is probably common between the different methods.  However, I am in desperate need to make progress on the goal of getting the processor to boot on its own (ie. without a development pod), as this is holding up additional hardware validation testing.  My management is highly motivated on this subject and I am getting a lot of heat for holding up the project. (ie. why I am willing to my night hours to match your day hours...)  I am back in the office now and willing to try any suggestion you have.

Brad,

Alright.

I need some time to review your DDR3 calulation spread sheet with respect to your DRAM chip used.

---

Meanwhile you can do this:

DDR3 debug source code is available here ----->https://www.ti.com/lit/an/sprac04/sprac04.pdf ( In the page no:1, third line ) 

( After Downloading “sprac04.zip” http://www.ti.com/lit/zip/sprac04, unzip and find the gel, “Keystone2_DDR_Debug_v1_4.gel ”) 

1. Download, modify the source code for Keystone-I

2.   Modify your custom hardware gel file by comparing to the Keystone2_DDR_Debug_v1_4.gel 

---

This will debug your DDR3 in your custom hardware.

Regards

Shankari G 

While you have been away, I have turned by attention toward the operation of the IBL.  I have a few questions regarding it's operation.

1. Is there a document that provides a detailed explanation of the IBL? Similar to the document for the RBL (SPRUGY5C).
2. I am trying to figure out what/where is the first statement executed after loading the IBL form I2C memory. The make files are a little confusing, so I have not been able to completely trace build of the IBL. I have found the main(void) function, assumed to be the first statements executed, defined in several files. This makes me believe that there are 6 applications within the IBL source code. Which one is executed first?
   1. C:\ti\pdk_c665x_2_0_16\packages\ti\boot\ibl\src\main\iblinit.c
   2. C:\ti\pdk_c665x_2_0_16\packages\ti\boot\ibl\src\main\iblmain.c
   3. C:\ti\pdk_c665x_2_0_16\packages\ti\boot\ibl\src\test\test1\test1.c
   4. C:\ti\pdk_c665x_2_0_16\packages\ti\boot\ibl\src\test\test2\test2.c
   5. C:\ti\pdk_c665x_2_0_16\packages\ti\boot\ibl\src\util\i2cConfig\i2cparam.c
   6. C:\ti\pdk_c665x_2_0_16\packages\ti\boot\ibl\src\util\iblConfig\src\iblConfig.c
3. In one of the test1.cmd file (assumed to be an example application loadable by the IBL) there is a comment that states that “the memory must not conflict with the IBL”. What memory is used by the IBL (i.e. what memory should I not use with my application)? Where is this defined?
4. Build instructions. Have I missed a document that explains how to build/format my application to be loaded with the IBL? How does the out file need to be manipulated to be loadable by the IBL / would you point me to where this documentation is?

I would appreciate any insight you can provide.

Brad

Since my last post I now have the IBL operating on my custom hardware. For others reading these posts the following is a summary of what I have learned.

1. Upon boot the processor's ROM boot loader (RBL) reads the bootmode pins and starts attempting to load code from this location. In this case the RBL loads the code from iblinit.c and starts executing from main() in this file.
2. This code identifies the location of next the next part of the bootloader. This is accomplished by the iblEnterRom() function of this project. In my case the iblmain is located on the I2C EEPROM at Addr 0x51. So this function was replaced by by a write to the DEVSTAT register of 0x080B.
3. Then somewhere in the remainder of the file the iblmain.c is loaded and started executing.
4. The main() in iblmain.c
5. In the deviceDdrConfig() needs to be adjusted to support your custom hardware.
6. I do not know how/why but the ibl then attempts to load to load the user application from SPI NOR

Other things I have learned.

1. The user needs to modify the TI provided GEL file for your custom hardware.  This is what allows to connect and validate the customer's configuration of the processor. (i.e. PLLs and DDR3 memory in particular)
2. Modify the example  "platform_test_evmc6657l" and associated library "platform_lib_evmc6657l" for your hardware.  This allows the customer to validate attached hardware to the processor (i.e. DDR3, EEPROM and SPI NOR in particular)
3. The loading of the EEPROM was hard to get done correctly.  Even if you create a proper IBL image, you need to get it properly loaded onto the hardware.  After loading the "eepromwriter_evm6657l.out" EEPROM writer application, you need to load IBL image to be written. This is accomplished by loading the image into the processor memory (Tools->Load Memory). For me to get the image in properly I needed to load the i2crom.bin file as File Type: TI Raw Data, Start Address of 0x0c000000, and Type-size of 32 bits.

Question.

The IBL image is very large and takes a significant amount of time to load.  In the IBL code there are several preprocessor directives that would limit the amount of code being included in the image (i.e. EXCLUDE_NOR_SPI,  EXCLUDE_ETH).  How did/does TI envision how the user is to properly set these preprocessor definitions?  Would you please provide an example?

Brad,

The only reference is the TI-C6657 EVM along with the FAQ guide posted here: 

https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1057566/faq-tms320c6657-how-to-flash-the-ibl-intermediate-boot-loader-into-eeprom-and-how-to-flash-the-application-binary-into-nor-how-to-boot-the-ibl-application-binary

---

The other few DOxygen document will be available at : 

IBL Configuration: Modules located at C:\ti\pdk_c665x_2_0_16\packages\ti\boot\ibl\doc\IBL-Configuration after installing the "Processor SDK 6.3" from http://software-dl.ti.com/processor-sdk-rtos/esd/C665x/latest/index_FDS.html

--

BradS said:

Question.

The IBL image is very large and takes a significant amount of time to load.  In the IBL code there are several preprocessor directives that would limit the amount of code being included in the image (i.e. EXCLUDE_NOR_SPI,  EXCLUDE_ETH).  How did/does TI envision how the user is to properly set these preprocessor definitions?  Would you please provide an example?

The customer is expected to have a hand-on the TI-C6657 EVM following the FAQ guide.

And then, with the help of the documents provided in the DOxygen guide, have a code walk through and modify according to their requirements of custom hardware...

---

For example, 

The boot modes for the IBL is documented at IBL Configuration: Defines the boot modes supported by the IBL 

located at C:/ti/pdk_c665x_2_0_16/packages/ti/boot/ibl/doc/IBL-Configuration/group__ibl_boot_modes.html after installing the "Processor SDK 6.3".

Regards

Shankari G